I’ve been using Ubuntu on my only phone for over six months now, and I’ve been loving it. But all this time it’s been missing something, something I couldn’t quite put my finger on. Then, Saturday night, it finally hit me, it’s missing the community.
That’s not to say that the community isn’t involved in building it, all of the core apps have been community developed, as have several parts of our toolkit and even the platform itself. Everything about Ubuntu for phones is open source and open to the community.
But the community wasn’t on my phone. Their work was, but not the people. I have Facebook and Google+ and Twitter, sure, but everybody is on those, and you have to either follow or friend people there to see anything from them. I wanted something that put the community of Ubuntu phone users, on my Ubuntu phone. So, I started to make one.Community Cast
Community Cast is a very simple, very basic, public message broadcasting service for Ubuntu. It’s not instant messaging, or social networking. It doesn’t to chat rooms or groups. It isn’t secure, at all. It does just one thing, it lets you send a short message to everybody else who uses it. It’s a place to say hello to other users of Ubuntu phone (or tablet). That’s it, that’s all.
As I mentioned at the start, I only realized what I wanted Saturday night, but after spending just a few hours on it, I’ve managed to get a barely functional client and server, which I’m making available now to anybody who wants to help build it.Server
The server piece is a very small Django app, with a single BroadcastMessage data model, and the Django Rest Framework that allows you to list and post messages via JSON. To keep things simple, it doesn’t do any authentication yet, so it’s certainly not ready for any kind of production use. I would like it to get Ubuntu One authentication information from the client, but I’m still working out how to do that. I threw this very basic server up on our internal testing OpenStack cloud already, but it’s running the built-in http server and an sqlite3 database, so if it slows to a crawl or stops working don’t be surprised. Like I said, it’s not production ready. But if you want to help me get it there, you can get the code with bzr branch lp:~mhall119/+junk/communitycast-server, then just run syncdb and runserver to start it.Client
The client is just as simple and unfinished as the server (I’ve only put a few hours into them both combined, remember?), but it’s enough to use. Again there’s no authentication, so anybody with the client code can post to my server, but I want to use the Ubuntu Online Accounts to authenticate a user via their Ubuntu One account. There’s also no automatic updating, you have to press the refresh button in the toolbar to check for new messages. But it works. You can get the code for it with bzr branch lp:~mhall119/+junk/communitycast-client and it will by default connect to my test instance. If you want to run your own server, you can change the baseUrl property on the MessageListModel to point to your local (or remote) server.Screenshots
There isn’t much to show, but here’s what it looks like right now. I hope that there’s enough interest from others to get some better designs for the client and help implementing them and filling out the rest of the features on both the client and server.
Not bad for a few hours of work. I have a functional client and server, with the server even deployed to the cloud. Developing for Ubuntu is proving to be extremely fast and easy.
The revelations from Edward Snowden concerning massive surveillance of communications demonstrates the need for each person to be able to control their computers and phones.
Yet computer and telephone manufacturers and retailers typically impose on users programs that jeopardise their privacy.
Each person should therefore have the opportunity to refuse to pay for non-Free software, and be allowed to choose the programs that run on their telephone and computer.
Today, Association for the free digital culture – CLibre joins other organisations throughout the world in requesting an unfettered choice of the operating system on telephones, laptops and other computing devices.
Sign the international petition! http://no.more.racketware.info/petition/click/en
Further information. http://no.more.racketware.info/en/index
Do you want help in promoting this petition? Visit http://no.more.racketware.info/petition/indexTweet
I have lots of positive things to say about the OpenStack community. They managed to create a great mixture of professional yet agile and FLOSSy. Amazing CI/CD and devstack is just an awesome way to kickstart development on OpenStack.
Last month I discovered Marconi (https://wiki.openstack.org/wiki/Marconi)...
Basically its a new MQ written in pure Python and allos different backends. The awesome thing is you can run it without having to run the whole openstack stuff and it works... It is still a young project but the community around it its awesome ans their IRC #openstack-marconi is very responsive. These guys could use a hand so if you are a Python enthusiast or want to hack on something OpenStack related without needing to have the whole stack running, please show some support and try to help out. There is a lot of low hanging fruit (https://bugs.launchpad.net/openstack/marconi) :)
The Ubuntu webbrowser sets its own default user agent string, and also provides a list of overrides which define different user agent strings for specific sites that do broken UA sniffing. This is a concept that we’ve borrowed from Firefox OS.
With QtWebkit, the overriding is performed via the same mechanism that is used for setting the default user agent string – by setting the WebViewExperimental.userAgent property. However, this has a major shortcoming – it provides no means to override the user agent string for specific frames. Say, for example, that you need to provide an override for www.twitter.com, but not for www.example.org. If a page from www.example.org embeds www.twitter.com in an iframe, there isn’t a mechanism to change the user agent string for the child frame.
When overriding the user agent string for a frame, there are 2 places that this needs to happen:
- The User-Agent header in outgoing HTTP requests.
Fortunately, Chromium provides a mechanism by which we can implement the second one – net::NetworkDelegate::OnBeforeSendHeaders(). Unfortunately, this is called on Chromium’s IO thread which makes it difficult to expose as a signal in QML (a QML engine can only execute code on a single thread). The notification is asynchronous, which means we could dispatch an event to the UI thread, emit a signal in QML and then dispatch an event back to Chromium’s IO thread. However, this has shortcomings of its own:
- A typical page load can generate more than 100 network requests. For example, loading BBC News generated 165 requests when I tested it here. Assuming we have multiple notifications per request, processing all of these on the UI thread in QML could have a noticeable performance impact.
- Not all notifications we get from net::NetworkDelegate are asynchronous. For example, cookie access permission requests aren’t.
For handling events that happen on Chromium’s IO thread, we have a new class – WebContextDelegateWorker. This is very similar to QML’s WorkerScript – it runs script on a worker thread and provides sendMessage/onMessage API’s for exchanging data with QML on the UI thread. However, it provides a mechanism for scripts to expose entry points that can be called from Chromium’s IO thread (actually, they’re not called from Chromium’s IO thread – they’re called on the worker thread by blocking the IO thread. But, you don’t need to care about that).
To overridethe User-Agent header for specific requests in Oxide, you can do something like the following:
This doesn’t affect navigator.userAgent though. In order to provide an override mechanism for this, we had to apply a small patch to Chromium to give embedders the opportunity to provide an override value when accessed. We did consider exposing a signal in QML for overriding this, based on the assumption that this would run much less frequently than network notifications. However, in the end we decided to reuse WebContextDelegateWorker, based on the assumption that developers who want to override navigator.userAgent will probably also want to use the same overrides for the User-Agent header. Doing this means that you only need the override list in one script context.
To override navigator.userAgent, the above code becomes:
Oxide doesn’t have a per-WebView property that’s equivalent to WebViewExperimental.userAgent in QtWebkit, as we decided that this would be redundant with the above override mechanism. Instead, the default user agent string is configured by setting the WebContext.userAgent property.Other uses for WebContextDelegateWorker
WebContextDelegateWorker is also used for overriding the default storage access policy via WebContext.storageAccessPermissionDelegate (in QML) and exports.onStoragePermissionRequest (in the worker). This is currently only used for cookies, but is due to be expanded to local storage, app cache, indexedDB and WebDB. The default storage access policy is controlled by WebContext.cookiePolicy
dict.has_key() was removed in Python 3.x.
This sed regex could fix them all:sed -r "s/([a-z,A-Z,0-9,.,_]*)\.has_key\('([^']*)'\)/'\2' in \1/g" \ -i `find -name "*.py"`
With the very latest great news – Ubuntu GNOME 14.04 will be an LTS release supported for 3 years – and with the great commitment of Ubuntu GNOME Team and the high quality that everyone showed for the last 5 months, we do need to carry on and keep up the great work. We have achieved a lot and less than a month to go to the final release and the very first LTS version of Ubuntu GNOME. The hard work has just started. Beta 2 or the final beta means this is what Ubuntu GNOME 14.04 LTS final release will look like, at least 90% or even more.
If you take a look at the Release Schedule Wiki Page, you will notice that there will be no more new features or any kind of changes to be done. At this stage/phase, it is mainly heavy testing and bugs fixing.
From today until 17th of April, 2014 (the date of the final release), we do need to make sure that Ubuntu GNOME 14.04 LTS will be solid and stable as a rock. Thus, we do need your help and support.
Final Beta or Beta 2 is not yet released. It will be released in 27th of March, 2014 but we must start testing from now and be ready.
What exactly do I need to test?
Ubuntu GNOME Trusty Tahr Daily Build
Okay, I’m new to this so how can I get started?
HOWTO Test Ubuntu GNOME
How can I get in touch with the Testing Team?
HOWTO Contact Ubuntu GNOME QA/Testing Team
Where else I could ask for some help?
Beside the mailing list of Ubuntu GNOME QA Team and Ubuntu GNOME IRC Channel, you can always post on Ubuntu Forums. There is a dedicated section for testing. However, please pay attention to:
This forum is for the discussion of the development of the next version of Ubuntu. Please Note: Ubuntu Developers do not usually read the forums, If you run into what you think is a bug, please use Launchpad to report it.
For anything else, please feel free to contact us.
Thank you for testing Ubuntu GNOME and helping us. We highly appreciate and respect that.
Ubuntu GNOME QA Lead
UbuConLA is an international event which happens every year and it is held in different parts of Latin America. This year UbuconLA will be in the beautiful city of Cartagena / Colombia. With the following objectives:
- Sharing the experiences and skills acquired in corporate environments by specialists from Latin America in several projects and contexts.
- Showing the level reached by Ubuntu GNU / Linux and professionals working in business environments, as well as consultants, users or systems managers.
- Technically and socially integrate users and specialists from Latin America, both for acquisition of new knowledge and skills and taking advantage of the creation business opportunities in the region.
- Spreading the Ubuntu spirit throughout Latin America.
- Institutionalizing UbuConLA as “The Annual Ubuntu Event “for Latin America.
The 2014 edition will be held in Cartagena, Colombia, at the Universidad Tecnologica de Bolivar on the 14 and 16 of August 2014.
This edition of the UbuConLA will be having people from, Argentina, Uruguay, Peru, Mexico, Venezuela, Colombia and Spain.
Besides if you want to be an speaker, visit http://ubuconla.org/callforpapers.php
And always is good to see Jono’s messages :D (this for ubuconla2013)
More news and updates on our social networks:
You can get more information on our website http://ubuconla.org/ or contact email the organizers at: ubuconla2013 [AT] ubuconla [DOT] org
In the modern display stack there are five main components:
- Display Server / Shell
- Toolkit / Platform API
For (too) many years we've lived with the X display server in the open source world. But now we are moving into next generation display servers (as Apple and Microsoft did many years ago). At the moment there are two new classes of contender for X replacement, Mir and a set of Wayland based compositors (e.g. weston, mutter-wayland etc).
Applications use toolkits and platform APIs to access graphical functionality. There are plenty of toolkits out there (e.g. GTK+, Qt) and existing libraries are growing more broad, consistent and stable to be considered as a complete platform API (which is great for developers).
If you read the Internet you would think the most important part in this new world is the display server. But actually it's just a detail that doesn't matter that much.
- Applications access the display server via a toolkit. All the successful toolkits support multiple backends because there's more than one OS out there today. In general you can take a GTK+ application and run it in Windows and everything just works.
- The hardware and drivers are becoming more and more generic. Video cards used to have very specialised functionality and OpenGL used to provide only a fixed function function. Now video cards are basically massively parallel processors (see OpenCL) and OpenGL is a means of passing shaders and buffer contents.
So what does matter now?
- It does matter that we have open drivers. Because there will be different things exercising them we need to be able to fix drivers when display server B hits a bug but A doesn't. We saw this working with Mir on Android drivers. Since these drivers are only normally used by SurfaceFlinger there are odd bugs if you do things differently. Filing a bug report is no substitute to being able to read and fix the driver yourself.
- The shell matters a lot more. We're moving on from the WIMP paradigm. We have multiple form factors now. The shell expresses what an application can do and different shells are likely to vary in what they allow.
I am entitled to my opinion and in my honest opinion: scrum sucks big time
Here is why (again my opinion).
Does not empower developers to become creative. Good way to sell that the developers are doing something (so that failure is not their fault) even if running around in circles ==> plausible deniability
Highly motivated developers are limited from jumping out of the “plan” to hack on other project related stuff (even doing so in free time is regarded wrong since you are not sticking to a plan). Thus limiting the personal success story and relying on motivation to come from team achievements. So being a weak link in a team just makes matters worse.
The “Daily Stand-up" routine is not productive in its defined structure of:
- What did I accomplish yesterday? Tried to finish a story. Ran out of time.
- What will I do today? Will try to finish this story.
- What obstacles are impeding my progress? This meeting, the circle jerk around legacy code and the dude demanding me to discuss every merge request before submitting it. (Just accept/deny with a comment - thank you ;) )
Stories over quality: Developers are keen to finish as much stories as possible which could to take a toll on the quality.
Not applicable on a distributed community of volunteers, or when dependency on open source community exist.
Time-boxed problem solving does not guarantee best possible outcome.
The commitment: One of the reason Scrum fails is its approach on commitment. "Deliver the maximum value of stories in a specific time frame”. As soon as the team can not agree on committing to a story all other stories with lower priority are ignored. And once done with those stories you pick the one out of the backlog that you couldn’t agree on (Since it has the highest priority) and waste time on it. You can’t skip this story since it has the highest priority. To me this is like sitting in an exam and being stuck on a problem. Instead of moving to the next problem with the hope of gathering as much points as possible, one decided to be stubborn and try fucking with that problem. That is just stupid. Now assume I solved the problem. Scrum now forces me to pick something from the backlog. And not anything. But the one with the highest priority and again waste time being stuck on that until the time ends. If would have adapted this style of tackling problems during school I would have never passed.
Don't get me wrong Scrum can work don't know how personally but I do believe it can work with the right team and people, however what are the chances of it succeeding if 2 or more of the following apply:
You don't have full control of the stack (dependency on third party)
Your developers are not all on the same level of expertise and knowledge.
Shoehorned into an ongoing running process and code base.
Stories of the team are not focused on a specific topic but on the general delivery of the whole project.
I look at GNOME, Mozilla and the Kernel. They don’t follow this methodology and stuff happens and gets delivered. So much big companies can learn from FLOSS.
For these to be a success, we need your help. The updates will have news from the LoCo Council, and will also highlight what LoCo Teams are doing around the world! That means, if your LoCo Team is having an event or wants to be mentioned on the show for something they are going to do or have already done, you need to tell us so we can feature it.
All LoCo Teams are welcome to send their news to us so they can be featured on the show. Just send an email to email@example.com, and make sure to start the subject with [LoCo Update]. An example of a subject would be “[LoCo Update] Release party hosted!” (don’t forget to mention which LoCo Team this is coming from!)
You can send text so we can read, but you can also send us your pictures and photos of the event, so we can show them to the world on this show. These sessions are all about you and your LoCo Team, so we are totally welcome to suggestions about what can be done in the future to improve the show. We may even start having some guests from LoCo Teams! Also, we will be using the #ubuntu-on-air channel on irc.freenode.net (Click here to join from your browser) to host discussion about the session. Anyone is welcome to come!
Our first session is going to be on Saturday, March 22nd, at 19 UTC. From that point on, we will be having sessions on the fourth Saturday each month, at the same time. You will be able to see the sessions at the Ubuntu on Air! calendar.
We hope to see you there, and expect to receive many news to be featured on the show!
Tagged: LoCo Council
I’ve made a new release of my curiously popular SteamOS derivative, and given it a new name: Stephenson’s Rocket.
You can download the new release from here.
- Updated to alchemist_beta 93
- Support for pre-HD5000 Radeon cards
- Support for motherboard-based “FakeRAID”
- Video tutorial series – about an hour of instructional material for all competency levels
One of the (many) challenges with creating a new mobile platform is that of bootstrapping app developers. The Ubuntu SDK – based on well known tools like Qt & QtCreator and supporting HTML5, C++ & GL – we can run our applications both on mobile devices and standard Ubuntu desktops.
With our convergence plans being a core component of Ubuntu over the coming releases, we can take advantage of this when testing mobile apps.
Developers can create & users can test applications without having to commit funds to a dedicated Ubuntu mobile device. Of course in the future Ubuntu mobile devices will be ubiquitous but for now we can support those users, testers and developers right now to use Ubuntu mobile apps on the desktop.
So with the Core Apps Hack Days just around the corner, now is a great time to install the core apps on your desktop and help test them, file bugs and contribute patches!
For users of Ubuntu 13.10 and Trusty (14.04) we have a Core Apps Daily PPA which has builds of all the core apps. Installing them is a cinch on 13.10 and 14.04 via the PPA & touch-coreapps metapackage:-
sudo add-apt-repository ppa:ubuntu-touch-coreapps-drivers/daily
sudo apt-get update
sudo apt-get install touch-coreapps
Note: This has been tested on 13.10 and 14.04 but not on previous releases.
If you later wish to remove them simply use sudo ppa-purge ppa:ubuntu-touch-coreapps-drivers/daily or just sudo apt-get autoremove touch-coreapps.
Once installed you should see icons for all the core apps in your dash
We welcome constructive feedback and bug reports about all aspects of the Core Apps. You can find us in #ubuntu-app-devel on freenode and details of where to file bugs can be found on the Core Apps wiki pages.
You can get started with developing apps on Ubuntu via the SDK, the documentation for which is at developer.ubuntu.com.Tweet
It’s been a while since I wrote my last blog post – Introducing Oxide. I’ve been quite busy since, so I thought that I should take this opportunity to provide a quick update on progress.
Our overall aim is to have the webapps container using Oxide in Ubuntu 14.04, and we’re also hoping to be able to transition the Ubuntu browser quite soon as well.Summary of progress
A lot has changed since my last post:
- runs independently of X11
- supports accelerated compositing on both Mir and X11
- has been running on several devices with Ubuntu Touch – Nexus 4 (mako), Nexus 7 (grouper) and Galaxy Nexus (maguro)
- has a navigation history API (WebView.navigationHistory)
- has a WebPreferences API (WebView.preferences)
- is DPI aware
- has input method support, and the onscreen keyboard works on Ubuntu Touch
- has support for touch events and gestures (pinch-to-zoom and fling works)
- supports third-party cookie blocking
- has a mechanism for intercepting and modifying outgoing HTTP requests, which can be used for redirecting URL’s or modifying headers (such as User-Agent)
- has a mechanism for intercepting accesses to navigator.userAgent which allows applications to customize this on a per-frame and per-domain basis (more on this and the above point in another blog post)
In addition to this, I also have the following features in my review queue:
- Support for JS dialogs (alert, confirm etc)
- File picker support
- Cursor change support
- API for exposing favicons
- API for delivering console messages to embedders
Oxide also runs WebGL and plays video quite well on both the desktop and the device.
Here is a list of things we need to tackle quite urgently:
- Land Oxide in to the archive
- Bug 1259219 (Expose onNavigationRequested-like mechanism) needs implementing for the webapps container
- Bug 1267543 (Crash when visiting a page that requests geolocation) needs fixing
And then, there are some other major tasks which are still important but not complete blockers at the moment:
- Geolocation support (requires permission request API and an API key for Google’s geolocation service. Eventually, this should use the Ubuntu location service)
- Device access permission request API (for microphone and webcam)
- Support window.open() and HTML anchor ‘target=”_blank”‘
- Add a fullscreen API – the mobile version of Youtube requires this to play videos
- We need to join Chromium’s release train with the creation of beta and release branches
I also need to clear my review queue
For a more complete list of remaining work, please see the list of open bugs.Testing Oxide
Builds of Oxide are currently uploaded fairly regularly to the Phablet Team PPA. Feel free to download it, play around with the API and report bugs. Sorry, there’s no documentation yet, so you will need to look at the source code or ask me questions about how it works for now. It is quite easy to use though.
The PPA also contains a build of webbrowser-app that uses Oxide instead of QtWebkit. You can try this out, but if you do, you should be aware of the following caveats:
- It does replace the current webbrowser-app, which uses QtWebkit
- Whilst it’s ok for basic browsing, testing and bug reporting, there is still major functionality missing that means you probably don’t want to use it for day-to-day browsing just yet.
If you want to help make Oxide (and our web browser) awesome, please take a look at the list of currently open bugs. If you see anything that you’d like to work on, feel free to come and talk to me on IRC (I’m “chrisccoulson” on irc.freenode.net), and I’ll be glad to help out.Thanks…
For all the hard work from everyone who has contributed or contributing to Oxide so far: Olivier Tilloy, Alexandre Abreu, Jamie Strandboge, Justin McPherson and Maxim Ermilov.
Also, thanks to Bill Filler, David Barth and Pat McGowan for keeping everybody focused.
And to Parameswaran Sivatharman for his tireless efforts on Continuous Integration.
I’m really excited about this
Hack Days are back!
On March 25th – 27th 2014 from 09:00 – 21:00U UTC we’re having another round of Core Apps Hack Days as we Sprint towards the final Ubuntu 14.04 release in April.
This time we’re concentrating our focus on 6 main apps, but we welcome new contributions to all the core apps. We’re identifying all the bite-size bugs which would be ideal for new developers, and we have some more chunky work for more experienced developers looking for more of a challenge. Getting involved is really easy and it’s fun and friendly.
Music & Reminders will be the focus on Tuesday 25th.
Clock & Calendar on Wednesday 26th.
Weather & Calculator on Thursday 27th.
That said, we don’t want to limit contributions to just those days, and of course welcome community developers getting involved at any time of day or night!
We’ve detailed on the HackDays wiki page how you can get involved and all the other details. Head over there for more information.
David, Michael & myself will be around on IRC in #ubuntu-app-devel as always to co-ordinate and run the Hack Days. We’ll also be able to test on multiple mobile devices as well as desktops and laptops. We can review code and get completed work landed into trunk and on devices promptly. We’ll also have and other Core Apps community & Canonical platform developers around to consult and mentor where required.
If you’ve ever considered developing on Ubuntu, but not got around to it, now is a great time to join. There’s plenty to do for people of all levels, developing Free Software for a very wide audience. Join us and lets make the Core Apps rock!Tweet
Forkstat uses the kernel proc connector interface to detect process activity. Proc connector allows forkstat to receive notifications of process events such as fork, exec, exit, core dump and changing the process name in the comm field over a socket connection.
By default, forkstat will just log fork, exec and exit events, but the -e option allows one to specify one or more of the fork, exec, exit, core dump or comm events. When a fork event occurs, forkstat will log the PID and process name of the parent and child, allowing one to easily identify where processes are originating. Where possible, forkstat attempts to track the life time of a process and will log the duration of a processes when it exits (note: this is not an estimate of the CPU used).
The -S option to forkstat will dump out a statistical summary of activity. This is useful to identify the frequency of processes activity and hence identifying the top offenders.
Forkstat is now available in Ubuntu 14.04 Trusty Tahr LTS. To install forkstat use:
sudo apt-get install forkstat
For more information on the tool and examples of the forkstat output, visit the forkstat quick start page.
On the 25th of January, the Ubuntu Peru LoCo Team hosted the first Ubuntu App Dev School. We contacted the National Engineering University, and they offered their help in order to host the event at their premises.
After some planning, we showed up that morning. I was a bit rushed with everything as the connection on my PC was not good and I had to run an Ubuntu User Days session just before the event started, so I ended up running it from my phone. At 10:00 am, around 45 to 50 people joined us in the newly-opened auditorium, where we presented Ubuntu Touch to the community and explained how it all worked – from the foundations to app development. This was the first time the community had showed a device with Ubuntu Touch, and as I got my own Nexus 4 I decided to give it a try, and show it to the rest of the community.
Everything starting by showing the phone with the OS installed, and then we proceeded to explain how the system worked, the concepts inside the system, how edges work, and many more things that are featured on the phone. After this, we had a break, where we distributed some swag and DVDs/CDs we got from Canonical, as we are a verified team. We invited some people from the press, but as they didn’t show up we ended up having more time for the next part of the event. We continued by explaining how foundations and applications work, and we gave some tips on how to install Ubuntu on a machine or use a VM, install Ubuntu Touch on a phone or tablet, and terminal tips and tricks. We also explained the process of creating and publishing applications to the Ubuntu Click Store.
We encouraged people to write their own applications, whether they are in QML or HTML5. I had a couple spare YubiKeys from when I went to UDS-R (literally, a couple), so I decided to raffle them to the assistants. We got a bunch of numbered tickets and started giving them out to assistants, and then we raffled them as we kept the other side of the ticket (works great if you decide to do a raffle in your LoCo Team!). We hoped this was an incentive in order to increase security in their accounts and discovering what else can be done with Ubuntu.
Aaaand, that was basically it. Everyone ended up super happy, and knowing what the future of convergence is.
If you want to organize an App Dev School in your LoCo Team, it’s quite easy! Just make sure to read this page to have a general idea. Daniel Holbach and David Planella will be hosting two sessions at Ubuntu on Air! to answer all your questions about App Dev Schools – both organizational and technical. The first one is on the 26th of March at 9:00 UTC, and the second one is on the 27th of March at 18:00 UTC. Make sure you’re there if you want to ask anything about App Dev Schools. Also, if you want to use the slides I used for the presentation, they are on my people.ubuntu.com page, and fully translated to Spanish. The original slides can be found at Daniel’s people.canonical.com page, including also a VM with Ubuntu and the Ubuntu SDK installed. Now, I leave you with some photos from the event!
We’re not starting from scratch though, we’re building on top of the incredible work done in the Trojitá project. Trojitá provides a fast, light email client built with Qt, which made it ideal for using with Ubuntu. And yesterday, the first of that work was accepted into upstream, you can now build an Ubuntu Components front end to Trojitá.
None of this would have been possible without the help up Trojitá’s upstream developer Jan Kundrát, who patiently helped me learn the codebase, and also the basics of CMake and Git so that I could make this first contribution. It also wouldn’t have been possible without the existing work by Ken VanDine and Joseph Mills, who both worked on the build configuration and some initial QML code that I used. Thanks also to Dan Chapman for working together with me to get this contribution into shape and accepted upstream.
This is just the start, now comes the hard work of actually building the new UI with the Ubuntu UI Toolkit. Andrea Del Sarto has provided some fantastic UI mockups already which we can use as a start, but there’s still a need for a more detailed visual and UX design. If you want to be part of that work, I’ve documented how to get the code and how to contribute on the EmailClient wiki. You can also join the next IRC meeting at 1400 UTC today in #ubuntu-touch-meeting on Freenode.
Hummus is dead simple. Traditionally it's a paste of chickpeas, garlic, lemon and tahini, but I like to add a few other spices to give it more flavour.
- 1 can of your finest chickpeas, drained
- 3 cloves garlic, whole
- 1 tablespoon tahini (or 1 tablespoon each sesame oil & roasted sesame seeds)
- 1 tablespoon ground cumin
- 1/2 teaspoon ground paprika
- 1/2 teaspoon freshly ground black pepper
- 1/4 teaspoon ground cayenne pepper
- juice of one lemon
- salt to taste
- Just chuck all of the ingredients in a food processor and blend into a paste.
- Transfer into a bowl, garnish the top if you like, then cover and refrigerate –it gets better even after a short period in the fridge.
Guacamole is one of those things people either love or hate, I love it, and it's very easy to do.
Having said that, a classic mistake people make is blending all the ingredients –which one should never do. Instead a guacamole should be chunky, which is simply achieved by mashing everything.
- 3-4 ripe avocados –depending their size
- 3 cloves garlic, minced
- 1-3 jalapeno peppers, minced –depending on your tolerances
- 1 tablespoon olive oil
- 1 tablespoon fresh cilantro, finely chopped minced
- juice of one lime
- 1/2 teaspoon salt
Breaking Down the Avocados
- Halve the avocados by slicing to the pit and then running your knife around it slicing the avocado.
- Whack the edge of the knife into the pit, twist & pull, removing the pit. Discard.
- Scoop the flesh out with a spoon into a bowl.
- Repeat for all avocados.
- With your avocado flesh in a bowl, add the lime juice, salt, olive oil, chopped cilantro and minced garlic.
- Using a potato masher, mash the ingredients into the avocado until it's a chunky paste (see above).
- Stir in the minced jalapeno pepper.
- Taste and adjust the seasoning, if need be.
- Eat now or cover and refrigerate until use.