In this week’s show:-
- We take a look at what’s been happening in the news:
- Version 1.0 of Docker, the portable virtualisation container platform, has been released…
- Another serious security flaw has been found in OpenSSL…
- Alan Solomon, the man behind 90s anti-virus software Dr Solomon’s, has said that anti-virus software no longer works…
- Phone manufacturer Meizu have spoken out about their development of Ubuntu for their phone, the MX3…
- With more than double the crowdfunding target requested, “Superhot” is coming to Linux
- Steam hits 500 games for Linux…
- Civ 5 now on Linux (SteamOS)…
- We also take a look at what’s been happening in the community:
- And there’s an event:
- OggCamp 2014 – 4th-5th October – Oxford, UK
We’ll be back next week, when we’ll be discussing alternatives to Ubuntu One, which recently shut down, and we’ll go through your feedback.
Please send your comments and suggestions to: firstname.lastname@example.org
Join us on IRC in #uupc on Freenode
Leave a voicemail via phone: +44 (0) 203 298 1600, sip: email@example.com and skype: ubuntuukpodcast
Follow us on Twitter
Find our Facebook Fan Page
Follow us on Google+
On our Plasma 5 build status page most of the packages are now a pleasing green colour. For the first time today I installed them all and logged in and... it worked! It took a bit of removing old caches and obsolete installs that'd I'd been making in the months previously and that nice temporary Next wallpaper everyone uses doesn't really get shipped so I had to add that and the icons sometimes work and sometimes don't and there's no plasma-nm release yet so I had to grab a copy and build that before I could use the network. But with some fiddle and wee bit ay faff, it works!
Today is a beautiful day.
If you just want to try it out the Neon 5 ISO is the easiest way still. But the packages I'm pleased about today are the Next PPA packages which is the packaging Kubuntu (and hopefully Debian) will be using going forward. It doesn't co-install with Plasma 1 so only use if you want breakage and if you want to help fix breakage, join #kubuntu-devel and help out.
This post is part of the series ‘Making ubuntu.com responsive‘.
When working to make the current web style guide responsive, we made some large updates to the core Sass. We decided to update the file and folder structure of our styles. I love reading about other people or organisations Sass architectures, so I thought it would be only right to share the structure that has evolved over time here at Canonical.
Let’s get right to it.
I won’t describe each file as some are self-explanatory but let’s just go through the core files to understand the structure.
core.scss contains the core HTML element styling. Such as img, p, ul, etc. You could say this acts as a reset file customised to match our style.
core-constants.scss is home to all variables used throughout. This file contains all the set colours used on the site. Base font size and some extra grid variables used to extend the layout.
core-grid.scss holds the entire responsive grid styles. This file mainly consists of generated code from Gridinator which we extended with breakpoints to modify the layout as the viewport gets smaller. You can read more about how we did this in “Making ubuntu.com responsive: making our grid responsive”.
core-mixins.scss holds all the mixins used in our Sass.
core-templates.scss is used to hold full pages styling classes. Without applying a template class to the <body> of a page you get a standard page style, if you add a template class, you will get the styles that are appropriate for that template.
Web team front end working on the web style guide.Divide and conquer
Patterns were originally all in one huge scss file, which became difficult to maintain. So we decided to split the patterns file apart in a pattern folder. This allows us to find and work in a much more modular way. This involved manually working through the file. Removing all the components styles into a new file and import back into the same position.Naming conventions
Our mission when setting up the naming convention for our CSS was to make the markup as human readable as possible.
We decided early on to almost use a object oriented, inheritance system for large structural elements. For example, the class .row can be extended by adding the .row-enterprise class which applies a dark aubergine background and modifies the elements inside to be display correctly on a dark background.
We switch to a single class approach for small modular components, such as lists. If you apply the class .list the list items are styled with our simple Ubuntu list style. This can be modified by changing the class to .list-ubuntu or .list-canonical, which apply their corresponding branding themed bullets to the items.
The decision to use different systems arose from the desire to keep the markup clean and easy to skim read by limiting the classes applied to each element. We could have continued with the inheritance system for smaller elements but that would have lead to two or more classes (.list and .list-canonical) for each element. We felt this was overkill for every small component. For large structural elements such as rows it’s easier to start with a .row class and have added functionality and styling by adding classes.Mixins
We mainly use mixins to handle browser prefixes as we haven’t yet added a “prefixer” step to our build system.
A lot of our styles are quite specific and therefore would not benefit from being included as a mixin.A note on Block Element Module syntax
We would like to have used the Block Element Module (BEM) syntax as we think it is a good convention and easy for people external to the project to understand and use. Since we started this project back in 2013 with the above syntax, which is now used on a number of sites across the Canonical/Ubuntu web real estate, the effort to convert every class name to follow the BEM naming convention would far outweigh the benefits it would return.Conclusion
By splitting our bloated patterns file into multiple small modular files we have made it much easier to maintain and diagnose bugs within components. I would recommend anyone in a similar situation to find the time to split the components into separate files sooner rather then later. The effort grows exponentially the longer it’s left.
Introducing linting to the production of the guidelines will keep our coding style the same throughout the team and help readability to new members of the team.Reading list
I am a firm believer in building strong and empowered communities. We are in an age of a community management renaissance in which we are defining repeatable best practice that can be applied many different types of communities, whether internal to companies, external to volunteers, or a mix of both.
I have been working to further this growth in community management via my books, The Art of Community and Dealing With Disrespect, the Community Leadership Summit, the Community Leadership Forum, and delivering training to our next generation of community managers and leaders.
Last year I ran my first community management training course, and it was very positively received. I am delighted to announce that I will be running an updated training course at three events over the coming months.OSCON
On Sunday 20th July 2014 I will be presenting the course at the OSCON conference in Portland, Oregon. This is a tutorial, so you will need to purchase a tutorial ticket to attend. Attendance is limited, so be sure to get to the class early on the day to reserve a seat!
Firstly, on Fri 22nd August 2014 I will be presenting the course at LinuxCon North America in Chicago, Illinois and then on Thurs Oct 16th 2014 I will deliver the training at LinuxCon Europe in Düsseldorf, Germany.
Tickets are $300 for the day’s training. This is a steal; I usually charge $2500+/day when delivering the training as part of a consultancy arrangement. Thanks to the Linux Foundation for making this available at an affordable rate.
Space is limited, so go and register ASAP:
So what is in the training course?
My goal with each training day is to discuss how to build and grow a community, including building collaborative workflows, defining a governance structure, planning, marketing, and evaluating effectiveness. The day is packed with Q&A, discussion, and I encourage my students to raise questions, challenge me, and explore ways of optimizing their communities. This is not a sit-down-and-listen-to-a-teacher-drone on kind of session; it is interactive and designed to spark discussion.
The day is mapped out like this:
- 9.00am – Welcome and introductions
- 9.30am – The core mechanics of community
- 10.00am – Planning your community
- 10.30am – Building a strategic plan
- 11.00am – Building collaborative workflow
- 12.00pm – Governance: Part I
- 12.30pm – Lunch
- 1.30pm – Governance: Part II
- 2.00pm – Marketing, advocacy, promotion, and social
- 3.00pm – Measuring your community
- 3.30pm – Tracking, measuring community management
- 4.30pm – Burnout and conflict resolution
- 5.00pm – Finish
I will warn you; it is an exhausting day, but ultimately rewarding. It covers a lot of ground in a short period of time, and then you can follow with further discussion of these and other topics on our Community Leadership discussion forum.
I hope to see you there!
London's taxi "strike" today has been so successful that Uber claims to have had an 850% increase in new customer registrations this week. Well, that is a big success if you believe the strike may have been a guerrilla marketing tactic organised by Uber itself.No sympathy
Personally, I have no sympathy for the taxi drivers. There is no city I have ever visited where I haven't encountered at least one taxi driver who tried to overcharge me.
When I broke a leg a few years ago and was getting about on crutches for 6 weeks we decided to go out for dinner one night. This was the first time I went anywhere after having a long stint in hospital followed by a period of time I was confined to the house. The taxi driver deliberately skipped two turns on a direct route to the restaurant, went another 1km past it and then followed a small street that winds back and forth and eventually demanded I pay him 20 CHF, double what the fare should have been.
This is exactly the type of abusive and despicable practice that is being eradicated by Uber's live GPS mapping technology.
This type of abuse of the weak or vulnerable is common around the world - for example, wheelchair taxis that have worked out they can make more money collecting families with suitcases at the airport while leaving genuine wheelchair users without a ride.Will Google be targeted next week?
Google has just announced a step-change in plans to build their own self driving cars. Will Google offices around the world, including London be targetted by these crude blockades too?Weapons of mass destruction
Why were taxi drivers not arrested for their protest today?
Before even having breakfast you could probably find 10,000 cyclists in central London willing to sign a petition declaring taxis are a weapon of mass destruction. I have personally experienced one of these brutal thugs ramming my bicycle from behind. The police who attended the incident even told me they had seen so many accidents like this they wouldn't dare cycle themselves.
The web is full of examples that appear to show criminal behavior by taxi drivers, thanks to Youtube and helmet cams:Will hotels protest about AirBNB?
Now the taxi drivers have had their chance to cause mayhem, will hotel operators be next?
What could they do though? Will they seek out AirBNB apartments and jam up the door locks with chewing gum perhaps? Chances are, they would be prosecuted for criminal damage. So why do the taxi drivers get to jam up whole cities and get away with it?The Uber taxi meter loophole
Will the courts decide that the Uber app is a taxi meter?
This is actually a tough question. Even if they rule against apps that perform live metering, Uber could simply remove all metering functions from the app itself and perform the metering calculations in the cloud. The app would just send start and finish locations to the cloud and the cloud would send a message back to the phone confirming the charge. The phone is then nothing more than a communication and positioning device.Remember the elevator man?
When the automobile was first invented, laws were made requiring every car to be accompanied through public streets by a man carrying a flag. That job, like many others, no longer exists.
In the good old days, every elevator had a man or woman who would sit on a stool and press buttons to operate the doors and motors.
Some up-market department stores and hotels still have an elevator man to add a touch of nostalgia. The vast majority, however, have eliminated these jobs thanks to automatic elevators.
Now, even aircraft can land automatically on a ship at sea. Look at all those people manning the deck in the video and contemplate how many of them might potentially be out of a job too in 50 years time as Terminator-style automated battleships patrol the seas.
Technology, like the Terminator, is not going to stop.
One of the things we’re keen to continue to push with Ubuntu is a spirit of openness and inclusivity. Over the last couple of years with the reduction in ‘in person’ Ubuntu Developer Summits it’s been said Canonical developers are harder to reach, and that we’re not communicating effectively our plans and designs for the future direction of Ubuntu. We’ve been trying to address this via increased blogging, regular email status updates and video updates from all areas of the community.
As always we’re also keen to hear feedback, we welcome email discussion on our lists, bug reports, design mock-ups and of course well tested patches. We also want to ensure people at every level are available for Q&A sessions on a regular basis. Jono Bacon had a series of Q&A sessions which the Community Team will continue, but with additional domain experts and leaders during those sessions.
One of the biggest visible areas of change for Ubuntu is the transition from Unity 7 on Compiz (used in 14.04 and below) and Unity 8 and Mir (to be used in future releases). So today this weeks Ubuntu Online Summit we’ve arranged a couple of sessions which we invited participation in.
At 14:00 UTC today Rick Spencer (VP of Engineering) and Oliver (Olli) Ries (Director of Unity & Display Server) will hold an Ask Rick & Olli session. Bring along your questions about Unity, Mir, convergence, future desktop direction and more.
Click the time links above to find out when these are happening in your timezone today, and the other links to join in the sessions at that time. If you miss it you can watch the sessions later using the same links.Tweet
Canonical Design Team: Making ubuntu.com responsive: updating font sizes and increasing readability (11)
This post is part of the series ‘Making ubuntu.com responsive‘.
All our designs are created using the Ubuntu font, and the websites are not exception. Ubuntu.com was already using a carefully refined and tested typographic scale that we have evolved over the years.
Early in the project, we had decided that the large screen view of the website would be kept, so we would be reusing the original styles (with some updates and clean up) and it became the typographic scale for the desktop view.Adjust as needed
After some device testing to adjust paragraph size for comfortable reading, we settled on having the base font size modified at our grid breakpoints to 14px, 15px and 16px.
By keeping the proportions of the sizes though, it was easy to see that some font sizes and margins were too large in proportion to others at small screens — especially the larger headings like h1 —, so we tweaked these as needed to improve readability.
A typographic scale can serve as a guide, but you don’t have to stay married to it: adjusting sizes to what feels better is an important step in making sure your text is comfortable to read at various sizes — and the best way to test this is on the actual devices!
Testing ubuntu.com on various devices.Use ems
Our typographic scale is defined in pixels, but the sizes are specified in ems in our CSS so they can be scalable.
Differences in the typographic scale from small to large screens.Reuse existing patterns
We have a weekly designers meeting where we talk about new patterns we’re working on in our separate projects across the entire design team. This way, we minimise the risk of creating new patterns when existing ones are in place, and when something new is created it can be shared with the rest of the team to use.
So we made sure to show our updated typographic scale and get everyone’s feedback on it, including designers from the apps and platforms teams. The best part was that we had reached similar conclusions about which sizes worked best in small screens (the variation was in the decimals) so we were all being consistent when it came to mobile!Remember fallback fonts
Even though web fonts are widely supported now, some browsers, like Opera Mini, just don’t support them, so it’s always a good idea to look at your site across various devices and browsers, and turn off the font-face declarations to see if the fallback fonts that you’ve declared look as good as you can make them and match as closely as possible with the original font. By doing this you’ll make the transition between the fallback font and the web font once it’s finally loaded less obvious and less jarring for the user.
Opera Mini, without the Ubuntu font.Conclusion
There are a few simple things you can do when transitioning from a fixed-width to a responsive website. The focus should be to improve readability, so it’s vital to check as many pages and screens of your site in different devices. And remember that picking a typographic scale is not as simple as taking numbers out of a generator: you have to see it in action and adapt it to your project.
We’d love to hear how you handled typography in your responsive projects — leave your thoughts in the comments area!Reading list
On Tuesday, June 10 2014, the Ubuntu Women Project participated in the Ubuntu Online Submit. These were the topics that were covered:
- Set a goal to host more Career Days sessions
- Give people a preview of the “Where should I contribute?” quiz that will be placed on community.ubuntu.com
- Develop Harvest into something usable for all
- Finish up uncompleted items from the last cycle
Thanks to everyone who participated and we’re looking forward to continuing discussions and work on all these items in the coming months.
Video from our session is available here:
Blueprint for this cycle available here: https://blueprints.launchpad.net/ubuntu-women.org/+spec/community-1406-ubuntu-women
A few weeks back, I was told that go code which uses cgo (that is utilising C api calls to shared libraries exporting C interface) cannot be cross-compiled. Well, if it's just calling out a C compiler it should totally be easy to cross compile, since so much of our platform is.
So there we go, first I've picked a moderately small project which only does a couple cgo calls, and check that it compiles correctly:
$ sudo apt-get build-dep ubuntu-push-client
$ go get launchpad.net/ubuntu-push/...
$ cd $GOPATH/src/launchpad.net/ubuntu-push/
$ go build ubuntu-push-client.goWell, when your gcc is all is easy.
I didn't want to polute my system, so I quickly created a chroot with go, build-dependencies in armhf architectures and cross-compiler:
# Get a chroot with build-dependencies installed, I am basing on top of a click-chroot
# one should be able to use any chroot which is armhf multiarch enabled.
$ sudo click chroot -aarmhf -fubuntu-sdk-14.04 -s utopic create
$ sudo click chroot -aarmhf -fubuntu-sdk-14.04 -s utopic maint apt-get install golang-go golang-go-linux-arm golang-go-dbus-dev golang-go-xdg-dev golang-gocheck-dev golang-gosqlite-dev golang-uuid-dev libgcrypt11-dev:armhf libglib2.0-dev:armhf libwhoopsie-dev:armhf libubuntuoneauth-2.0-dev:armhf libdbus-1-dev:armhf libnih-dbus-dev:armhf libsqlite3-dev:armhf crossbuild-essential-armhfAfter that the tricky bit was advising go to cross-compile:
$ click chroot -aarmhf -fubuntu-sdk-14.04 -s utopic run CGO_ENABLED=1 GOARCH=arm GOARM=7 PKG_CONFIG_LIBDIR=/usr/lib/arm-linux-gnueabihf/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig GOPATH=/usr/share/gocode/:~/go CC=arm-linux-gnueabihf-gcc go build -ldflags '-extld=arm-linux-gnueabihf-gcc' ubuntu-push-client.goIgnoring the click chroot wrapper:
- CGO_ENABLED=1 - by default cgo is disabled when cross-compiling, but really shouldn't be as compiler names are standard $(GNU_TRIPPLET) prefixed tools
- GOARCH=arm - set the target arch
- GOARM=7 - set ABI level
- PKG_CONFIG_LIBDIR - the ugly beast to pass where pkg-config should search for .pc files. With autoconf one simply sets PKG_CONFIG environment variable pointing at a cross-pkg-config, $(GNU_TRIPPLET)-pkg-config but go tool doesn't support it. I've raised merge proposal to get that added https://codereview.appspot.com/104960043/
- Next I just set GOPATH to where my packages are and CC as to which compiler to use
- The last portion to the puzzle was to pash "-ldflags '-extld=$CC'" because the linker tool (5l) didn't use environmental variable CC and simply defaults to gcc. I'll raise a merge proposal for this.