DidRocks' blog

apt-get install freedom

Aller au contenu | Aller au menu | Aller à la recherche

Mot-clé - programmation

Fil des billets - Fil des commentaires

mercredi, septembre 24 2014

Ubuntu Developer Tools Center: how do we run tests?

We are starting to see multiple awesome code contributions and suggestions on our Ubuntu Loves Developers effort and we are eagerly waiting on yours! As a consequence, the spectrum of supported tools is going to expand quickly and we need to ensure that all those different targeted developers are well supported, on multiple releases, always delivering the latest version of those environments, at anytime.

A huge task that we can only support thanks to a large suite of tests! Here are some details on what we currently have in place to achieve and ensure this level of quality.

Different kinds of tests

pep8 test

The pep8 test is there to ensure code quality and consistency checking. Tests results are trivial to interpret.

This test is running on every commit to master, on each release during package build as well as every couple of hours on jenkins.

small tests

Those are basically unit tests. They are enabling us to quickly see if we've broken anything with a change, or if the distribution itself broke us. We try to cover in particular multiple corner cases that are easy to test that way.

They are running on every commit to master, on each release during package build, every time a dependency is changed in Ubuntu thanks to autopkgtests and every couple of hours on jenkins.

large tests

Large tests are real user-based testing. We execute udtc and type in stdin various scenarios (like installing, reinstalling, removing, installing with a different path, aborting, ensuring the IDE can start…) and check that the resulting behavior is the one we are expecting.

Those tests enables us to know if something in the distribution broke us, or if a website changed its layout, the download links are modified, or if a newer version of a framework can't be launched on a particular Ubuntu version or configuration. That way, we are aware, ideally most of the time even before the user, that something is broken and can act on it.

Those tests are running every couple of hours on jenkins, using real virtual machines running an Ubuntu Desktop install.

medium tests

Finally, the medium tests are inheriting from the large tests. Thus, they are running exactly the same suite of tests, but in a Docker containerized environment, with mock and small assets, not relying on the network or any archives. This means that we ship and emulate a webserver delivering web pages to the container, pretending we are, for instance, https://developer.android.com. We then deliver fake requirements packages and mock tarballs to udtc, and running those.

Implementing a medium tests is generally really easy, for instance:

class BasicCLIInContainer(ContainerTests, test_basics_cli.BasicCLI):

"""This will test the basic cli command class inside a container"""

is enough. That means "takes all the BasicCLI large tests, and run them inside a container". All the hard work, wrapping, sshing and tests are done for you. Just simply implement your large tests and they will be able to run inside the container with this inheritance!

We added as well more complex use cases, like emulating a corrupted downloading, with a md5 checksum mismatch. We generate this controlled environment and share it using trusted containers from Docker Hub that we generate from the Ubuntu Developer Tools Center DockerFile.

Those tests are running as well every couple of hours on jenkins.

By comparing medium and large tests, as the first is in a completely controlled environment, we can decipher if we or the distribution broke us, or if a change from a third-party changing their website or requesting newer version requirements impacted us (as the failure will only occurs on the large tests and not in the medium for instance).

Running all tests, continuously!

As some of the tests can show the impact of external parts, being the distribution, or even, websites (as we parse some download links), we need to run all those tests regularly[1]. Note as well that we can experience different results on various configurations. That's why we are running all those tests every couple of hours, once using the system installed tests, and then, with the tip of master. Those are running on various virtual machines (like here, 14.04 LTS on i386 and amd64).

By comparing all this data, we know if a new commit introduced regressions, if a third-party broke and we need to fix or adapt to it. Each testsuites has a bunch of artifacts attached to be able to inspect the dependencies installed, the exact version of UDTC tested here, and ensure we don't corner ourself with subtleties like "it works in trunk, but is broken once installed".

jenkins test results

You can see on that graph that trunk has more tests (and features… just wait for some days before we tell more about them ;)) than latest released version.

As metrics are key, we collect code coverage and line metrics on each configuration to ensure we are not regressing in our target of keeping high coverage. That tracks as well various stats like number of lines of code.

Conclusion

Thanks to all this, we'll probably know even before any of you if anything is suddenly broken and put actions in place to quickly deliver a fix. With each new kind of breakage we plan to back it up with a new suite of tests to ensure we never see the same regression again.

As you can see, we are pretty hardcore on tests and believe it's the only way to keep quality and a sustainable system. With all that in place, as a developer, you should just have to enjoy your productive environment and don't have to bother of the operation system itself. We have you covered!

Ubuntu Loves Developers

As always, you can reach me on G+, #ubuntu-desktop (didrocks) on IRC (freenode), or sending any issue or even pull requests against the Ubuntu Developer Tools Center project!

Note

[1] if tests are not running regularly, you can consider them broken anyway

mercredi, septembre 10 2014

How to help on Ubuntu Developer Tools Center

Last week, we announced our "Ubuntu Loves Developers" effort! We got some great feedback and coverage. Multiple questions arose around how to help and be part of this effort. Here is the post to answer about this :)

Our philosophy

First, let's define the core principles around the Ubuntu Developer Tools Center and what we are trying to achieve with this:

  1. UDTC will always download, tests and support the latest available upstream developer stack. No version stuck in stone for 5 years, we get the latest and the best release that upstream delivers to all of us. We are conscious that being able to develop on a freshly updated environment is one of the core values of the developer audience and that's why we want to deliver that experience.
  2. We know that developers want stability overall and not have to upgrade or spend time maintaining their machine every 6 months. We agree they shouldn't have to and the platform should "get out of my way, I've got work to do". That's the reason why we focus heavily on the latest LTS release of Ubuntu. All tools will always be backported and supported on the latest Long Term Support release. Tests are running multiple times a day on this platform. In addition to this, we support, of course, the latest available Ubuntu Release for developers who likes to live on the edge!
  3. We want to ensure that the supported developer environment is always functional. Indeed, by always downloading latest version from upstream, the software stack can change its requirements, requiring newer or extra libraries and thus break. That's why we are running a whole suite of functional tests multiple times a day, on both version that you can find in distro and latest trunk. That way we know if:
  • we broke ourself in trunk and needs to fix it before releasing.
  • the platform broke one of the developer stack and we can promptly fix it.
  • a third-party application or a website changed and broke the integration. We can then fix this really early on.

All those tests running will ensure the best experience we can deliver, while fetching always latest released version from upstream, and all this, on a very stable platform!

Sounds cool, how can I help?

Reports bugs and propose enhancements

The more direct way of reporting a bug or giving any suggestions is through the upstream bug tracker. Of course, you can always reach us out as well on social networks like g+, through the comments section of this blog, or on IRC: #ubuntu-desktop, on freenode. We are also starting to look at the #ubuntulovesdevs hashtag.

The tool is really to help developers, so do not hesitate to help us directing the Ubuntu Developer Tools Center on the way which is the best for you. :)

Help translating

We already had some good translations contributions through launchpad! Thanks to all our translators, we got Basque, Chinese (Hong Kong), Chinese (Simplified), French, Italian and Spanish! There are only few strings up for translations in udtc and it should take less than half an hour in total to add a new one. It's a very good and useful way to contribute for people speaking other languages than English! We do look at them and merge them in the mainline automatically.

Contribute on the code itself

Some people started to offer code contribution and that's a very good and motivating news. Do not hesitate to fork us on the upstream github repo. We'll ensure we keep up to date on all code contributions and pull requests. If you have any questions or for better coordination, open a bug to start the discussion around your awesome idea. We'll try to be around and guide you on how to add any framework support! You will not be alone!

Write some documentation

We have some basic user documentation. If you feel there are any gaps or any missing news, feel free to edit the wiki page! You can as well merge some of the documentation of the README.md file or propose some enhancements to it!

To give an easy start to any developers who wants to hack on udtc iitself, we try to keep the README.md file readable and up to the current code content. However, this one can deviate a little bit, if you think that any part missing/explanation requires, you can propose any modifications to it to help future hackers having an easier start. :)

Spread the word!

Finally, spreading the word that Ubuntu Loves Developers and we mean it! Talk about it on social network, tagging with #ubuntulovesdevs or in blog posts, or just chatting to your local community! We deeply care about our developer audience on the Ubuntu Desktop and Server and we want this to be known!

uld.png

For more information and hopefully goodness, we'll have an ubuntu on air session session soon! We'll keep you posted on this blog when we have final dates details.

If you felt that I forgot to mention anything, do not hesitate to signal it as well, this is another form of very welcome contributions! ;)

I'll discuss next week how we maintain and runs tests to ensure your developer tools are always working and supported!

mardi, septembre 2 2014

Ubuntu loves Developers

Ubuntu is one of the best Linux platforms with an awesome desktop for regular users (and soon phone and tablets and more!) and great servers for system administrators and devops. A number of developers are choosing Ubuntu as their primary development system of choice, even if they develop for platforms other than Ubuntu itself, like doing some Android development, web development and so on.

uld.png

However, even if we fill the basic needs for this audience, we decided a few months ago to start a development and integration effort to make those users completely feel at home. Ubuntu loves developers and we are going to showcase it by making Ubuntu the best available developer platform!

Sounds great! What's up then?

We decided to start by concentrating on Android developers. We'll ramp up afterwards on other use cases like Go developers, web developers, Dart… but we want to ensure we deliver a stunning experience for each targeted audience before moving on to the next topic.

After analyzing how to setup an Android development machine on Ubuntu we realized that, depending on the system, it can takes up to 9 different steps to get proper IDE integration and all the dependencies installed. The whole goal was to reduce that to one single command!

Concretely speaking, we created the Ubuntu Developer Tools Center, a command line tool which allows you to download the latest version of Android Studio (beta), alongside the latest Android SDK, and all the required dependencies (which will only ask for sudo access if you don't have all the required dependencies installed already), enable multi-arch on your system if you are on a 64 bit machine, integrate it with the Unity launcher…

launcher-integration.png

As said, we focused on Android Studio (based itself on Intellij IDEA) for now as it seems that’s where Google has been focusing its Android tools development effort for over a year. However, the system is not restrictive and it will be relatively trivial in the near future to add ADT support (Android Development Tools using Eclipse)[1].

android-studio.png

Indeed, The Ubuntu Developer Tools Center is targeted as being a real platform for all developer users on Ubuntu. We carefully implemented the base platform with a strong technical foundation, so that it's easily extensible and some features like the advanced bash shell completion will even make more sense once we added other development tools support.

Availability

We will always target first the latest Ubuntu LTS version alongside the latest version in development. Yes! It means that people who want to benefit for the extensively tested and strong base experience that a Long Term Support version offers will always be up to date on their favorite developer tools and be first-class citizen. We strongly believe that developers always want the latest available tools on a strong and solid stable base and this is one of the core principle we are focusing on.

For now, the LTS support is through our official Ubuntu Developer Tools Center ppa, but we plan to move that to the backports archive with all the newly or updated libraries. For Utopic, it's already available in the 14.10 Ubuntu archive.

Initial available version

Be aware that the Ubuntu Developer Tools Center is currently in alpha. This tool will evolve depending on your feedback, so it's up to you to suggest the direction you want it to go! A blog post on how to contribute will follow in the next days. This initial version is available in English, French and Chinese!

Another blog post will expand as well how we test this tool. For now, just be aware that the extensive test suite is running daily, and it ensures that on all supported platforms we don't break, that the Ubuntu platform itself doesn't break us, or that any 3rd party on which we rely on (like website links and so on) don't change without us spotting it. This will ensure that our tools is always working, with limited downtime.

Example: how to install Ubuntu Developer tools and then, Android Studio

Ubuntu Developer Tools Center

If you are on Ubuntu 14.04 LTS, first, add the UDTC ppa:

$ sudo add-apt-repository ppa:didrocks/ubuntu-developer-tools-center $ sudo apt-get update

Then, installing UDTC:

$ sudo apt-get install ubuntu-developer-tools-center

How to install android-studio

Simply executes[2]:

$ udtc android

And then, accept the installation path and Google license. It will download, install all requirements alongside Android Studio and latest android SDK itself, then configure and fit it into the system like by adding an Unity launcher icon…

And that's it! Happy Android application hacking on Ubuntu. You will find the familiar experience with the android emulator and sdk manager + auto-updater to always be on the latest. ;)

android-sdk-tools.png

Feedback

We welcome any ideas and feedback, as well as contributions as we'll discuss more in the next post. Meanwhile, do not hesitate to reach me on IRC (didrocks on freenode, #ubuntu-desktop as the primary channel to discuss), or on Google+. You can as well open bugs on the launchpad project or github one

I'm excited about this opportunity to work on the developer desktop. Ubuntu loves Developers, and it's all on us to create a strong developer community so that we can really make Ubuntu, the developer-friendly platform of choice!

Notes

[1] For the technical audience, the Android Studio specific part is less than 60 lines

[2] android-studio is the default for the android development platform, you can choose it explicitely by executing "$ udtc android android-studio". Refer to --help or use the bash completion for more help and hints

vendredi, août 17 2012

Quickly reboot: Q&A session wrap up!

Last Wednesday, we had our Quickly reboot on air hangout, welcoming the community to ask questions about Quickly and propose enhancement.

Here is the recording of the session:

As for the previous sessions, we had a lot of valuable feedbacks and participation. Thanks everyone for your help! Your input is tremendous to shape the future of Quickly.

We are making a small pause in the Quickly Reboot hangouts, but we will be back soon! Meanwhile, you can catch up on the session notes, and provide feedback/ideas on this wiki page! Follow us on google+ to ensure to not miss any annoucement.

mardi, août 14 2012

Quickly reboot: Q&A sessions!

The previous Quickly reboot session about templates was really instructive! It started a lot of really interesting and opened discussions, particularly on the Quickly talks mailing list where the activity is getting higher and higher. Do not hesitate to join the fun here. :)

As usual, if you missed the on-air session, it's available here:

I've also summarized the session note on the Quickly Reboot wiki page.

Next session: Q&A!

But we don't stop here, the next session will be hold this Wednesday! If you read through the previous links, you will see a lot of pending questions we have still to discuss about, this will be used as the base conversation of the session. However, in addition to those topics, all of your questions will be taken into account as well! You can jump during the session on #quickly on freenode, while watching the show on ubuntuonair. You can as well prepare your questions and new ideas for Quickly, and post them to the google moderator page. There are plenty of ways to participate and help shaping the future of Quickly. Do not miss this session and subscribe to it right now.

Also, ensure you won't miss anything about Quickly and its reboot by subscribing to our google+ page.

lundi, août 6 2012

Quickly reboot: developer feedback wrap up and templates content

Previous sessions

The first two hangouts on Quickly reboot about developer feedback were really a blast! I'm really pleased about how much good ideas and questions emerged from those.

If you missed them, the hangouts on air are available now on youtube. Go and watch them if you are interested:

I've also taken some notes during the sessions, here are what I think was important and came from them: hangouts notes. It's a wiki, if you do have any feedback/questions/other subjects you want to get discussed, don't be shy and edit it! Quickly is a fully community-driven project and we love getting constructive feedbacks/new ideas from everyone. ;)

I've also added on it some nice spot of discussions for future sessions, and speaking of sessions…

Next step: default templates

Next session is a really important one: what should be the default templates in Quickly? From the previous discussions, seems that python + gtk, a html5 one and the already existing unity-lens ones are the good candidates. If so, what should be in every of each of those? How should look the default applications? Which framework (if any) in the case of html5 should we use? Should we make opinionated choices or just providing a default set? What should we provide as tools for them, and so on…

Join the conversation, I'm sure it will be a lot of fun! We plan to have the hangout at 4PM UTC on Wednesday. Ensure to follow it either by jumping in the hangout itself or by following the onair session. Mark it to down to you calendar not miss it!

Do not hesitate to follow the Quickly google+ page to not miss any future events and enhancements to Quickly.

lundi, juillet 30 2012

Time for a Quickly reboot?

Quickly is the recommended tool for opportunistic developers on ubuntu.

When we created it 3 years ago, we made some opinionated choices, which is the essence of the project. We had back then a lot of good press coverage and feedbacks (Linux Weekly NewsarstechnicaZdnetMaximum PC reviewShot of jak and some more I can't find on top of my head…)

Some choices were good, some were wrong and we adapted to the emerging needs that happened along the road. Consequently, the project evolved, the needs as well and we tried to make them match as much as possible. Overall, my opinion is that the project evolved in a healthy way, and has strong arguments seeing the number of projects using it successfully for the ubuntu developer contest. Indeed, from the ~150 submitted projects, most of them were created with Quickly and seeing the few support we needed to do, it means that most of things are working quite well! Also, the comments on the developer contest seems to be really positive about Quickly itself.

So? Time to go the beach and enjoy? Oh no… Despite this great success, can we do better? I like that sometimes, we can step back, look around, and restate the project goals to build an even brighter future, and I think now is this time and that's why I want to announce a Quickly reboot project!

quickly_reboot.png

Why a reboot?

We will need to port Quickly itself to python3, we have no hard deadline right now on it, but it's something (especially with unicode versus string) that I want to do soon. As this will ask a lot of refactoring, I guess it's time to evaluate the current needs, drop some code, completely use another direction to attract more 3rd party integrator (like do people want to integrate Quickly with their favorite IDE?), encourage template developers, make everything even more testable than today to avoid regressions… A lot of things are possible! So a reboot, meaning "let's put all aside, list what we have and what we want to do" is the appropriate term. :)

!Do you have a detailed plan right now of what is coming?

No… and that's exactly what I wanted! Well, of course, I have some ideas on papers and know globaly where I want the project to evolve, but the whole plan is to get the community contributing ideas, experiences before the first line of the reboot is even written.

I'm sold! how to participate?

I will run some google hangouts from the Quickly Google+ page. Those will be hangout on air (so you can just view them live or after the hangout without participating), asking questions/suggestions on #ubuntu-community-onair on freenode (IRC) for answering live, or you can jump in and ask directly during the show. :)

The current hangout will be also available (with an IRC chat box) on this page.

Those hangouts will be thematic to focus the discussion, and will be announced on the google+ Quickly page, this blog, the Quickly mailing list and so on…

First step… feedbacks, 2 chances to join!

The first step to build this Quickly next gen[1] is to gather some developers feedback. So, if you are a developer who used Quickly (or not!) and make softwares for ubuntu, in the context of the app showdown (or not!), we will love to ear from you! The goal of the session is not to point to any particular bug, but rather to share how the experience was for you, what template did you use, what template you would have used if it existed, what went well or bad with the workflow, when did you need to ask a question about a particular subjects? Of course, we are not limited to those questions.

You can directly jump into the hangout to ask your question live or just assist to the hangout on air and add a comment to the live event to get it read during the show.

The two first sessions will be live on different hours next Thursday and Friday: See those events are on the Quickly Google + page: subscribe to those hangouts on air to be sure to not miss them!

Next sessions?

Next topics in the following weeks will be:

  • listing the existings requirement
  • from the feedback from the first session, what needs to be added/dropped?
  • what need to be changed in Quickly to met it? Technical considerations (use of pkgme, templating system…)

all of this will be published on this blog and on the google+ page soon. I hope you are as excited as we are and will massively join us.

Note

[1] Term which seems to be use by the cool kids

jeudi, juillet 26 2012

Quickly: a path forward?

Seeing the amount of interests we saw around Quickly the past last years was really awesome!

Now that we have some more detailed view on how people are using the tool, it's time to collect and think about those data to see how we can improve Quickly. With all the new tools available like hangouts on air, it can be also now time to experiment how we can use them and use this opportunity to have a very open collaboration process as well as trying to attract more people to contribute to it. 

More on that next week. To ensure to not miss anything, please follow the Quickly Google+ page. :)

Lire la suite...

mardi, juillet 24 2012

Unity Radios lens for quantal

After having worked on the local radio scope for the music lens, I spent some time with pure python3 code, which made me experiencing a bug in Dee with pygi and python3 (now all fixed in both precise and quantal)

In addition to that, it was the good timing to experiment more seriously some mocking tool for testing the online part of the lens, and so I played with python3-mock, which is a really awesome library dedicated to that purpose[1].

So here was my playground: an Unity dedicated radio lens! You can search through thousands of online available radios, ordered by categories with some contextual informations based on your current language and your location (Recommended, Top, Near you).

Unity lens Radios full view

As with most of lenses you can refine any search results with filters. The supported ones are countries, decades and genres. The current track and radio logos are displayed if supported and double clicking any entry should start playing the radio in rhythmbox.

Unity lens Radios search and filter

Was a fun experiment and it's now available on quantal for your pleasure ;)

Oh btw:

didrocks@tidus:~/work/unity/unity-lens-radios/ubuntu$ nosetests3 ..................................................


Ran 50 tests in 0.164s

OK

Note

[1] loving the patch decorator!

mercredi, juillet 4 2012

Added rhythmbox radio support to unity music lens

Just got it merged (and will be freshly available in Unity 6.0 coming soon in quantal)!

I spent few hours last week to add rhythmbox radios (and writing unit tests) for the music lens. It's been a long time I didn't write some serious vala (I guess last time was for unity's Alt+F2). I confirm it's still not my favorite langage ;)

Coming back to the radios, they will now show as the last row (after tracks, albums and eventually online purchase ones), and they respect (if the metadata are provided in rhythmbox) to every usual music lens filters. Some obligatory screenshot: Rhythmbox radios in music lens

Coming soon, some more news about online radios searching directly in unity (just need a patch in dee for python3 support being released first) ;)

mardi, juin 12 2012

Cours python sur Ubuntu, débutant en programmation en ligne

Bonjour à tous,

je passe le message que Rick Spencer (un américain perdu en France depuis presque un an, responsable d'ubuntu engineering chez Canonical) veut lancer quelques sessions interactives[1] en français pour apprendre les bases de la programmation, en python. Python est un langage très accessible et excellent pour débuter dans ce domaine. Il permet aussi bien de créer de petits scripts que de vraies grandes applications (la plupart des applications spécifiques à ubuntu comme le software-center, update-manager, jockey, ubuntu one sont écrits dans ce language!).

Bref, n'hésitez pas à venir laisser un commentaire sur son blog pour trouver les meilleurs horaires si vous voulez participer à l'aventure !

Annonce sur le blog de Rick.

Note

[1] sûrement par google hangout