In case you missed it, Uber is an application that lets you request a car from your smartphone (there is an iOS version and an Android version). Up until recently, Uber only worked in a bunch of US cities (San Francisco, New York City, Seattle, Chicago, Boston and Washington DC) but now it also works in Paris. I was thrilled at this news, first because I can see myself using it someday in one of these two situations:
It’s 4 AM and I feel too bad to look for a regular cab or to take the Noctilien (A night bus service in Paris).
I lost my wallet that contained my credit card, my navigation pass and all my cash and I am too far from home to get there by walk. Since Uber requires you to associate a credit card during the subscription , you don’t have to pay anything to the driver because your will be automatically charged for the ride (even the tip is included).
By the way there might other occasions but right now I can only see these two, given that the service is a little bit expensive.
But the reason why I have a thing for Uber is that I (with two other persons) tried to build a similar service once.
Back in 2008 I decided (with two friends: Souad and Safa) to enter an annual competition sponsored and hosted by Microsoft, called Imagine Cup. Each year there is a theme and in 2008 we had to come up with solutions for protecting the environment. So back in August 2007, we started brainstorming many ideas, sketching them and after literally 3 months we had that *Eureka* moment when we thought about building a real-time carpooling solution.
PickMeUp was a mobile application that let you request a ride in real-time. It worked exactly like Uber except for one thing: every user could become a driver, whereas in Uber you have to be an official driver. This is the main reason why we used the word carpooling when pitching our idea while Uber doesn’t. Apart from this difference, there were many similarities in the way the product has been designed:
The positions of both the drivers and the riders were shown dynamically on a map.
Each user had an associated profile to match drivers and riders by their mutual interests.
After a ride, each of the driver and rider were invited to complete a feedback form and rate their partner according to the experience they had.
The price of the ride was calculated using a combination of both the distance between the pick up point and the destination, and the duration of the ride.
The users who didn’t have a Windows Mobile Phone, could have used the service by sending SMSs.
Yes you have read that last sentence right, the app was really built on a Windows Mobile device. In case you don’t believe me, here is a short demonstration that we used as a proof of conceptfor that competition (full disclosure: this is the first real app I have ever built, don’t expect much from the UX nor the quality of the demonstration) :
A few things you may have noticed:
The map was provided by Microsoft MapPoint (it’s funny right?).
It took us 4 months to build this prototype. Most of this time was spent working on the backend, on real-time issues and various optimisations. Very little time was spent on the design and the user experience of the application. Actually this application was built before mobile became trendy, it was only a few months after the iPhone came to the Market and way before the release of Android. As a matter of fact, the bar wasn’t very high and all the apps looked as crappy as this one on these kinds of platforms. Needless to say that I’m really embarrassed by this demo but heck, that was my first app ever and you can only learn by trying and making things. I knew that I sucked and I know that I still suck (probably less than before) but this is the reason why I wake up everyday: to suck less.
We somehow managed to win the regional final and we were qualified for the world wide final in Paris. We didn’t win there.
This app has never been used in real life, and it wasn’t actually ready for real life anyway for many reasons, the most obvious one is the choice of the platform itself. Also, we were still enrolled in college and we were living in an environment that wasn’t suitable for creating innovative companies.
What I feel from this last point, is that it’s important to be at the right place and at the right moment. In 2007/2008, having a Smartphone that could run rich apps was a big deal and very few devices were capable of offering a correct UX (The HTC Diamond was one of those). I wish we had the possibility to develop a working prototype on Android or iOS and I wish we were in an environment that favorited entrepreneurship and risk taking.
But let’s face it, the execution that Uber made feels just right. The fact that the drivers are requested to obtain a licence from Uber removes all the security issues. The fact that you are required to link your credit card during the subscription and that the price is calculated by the service makes the experience easy for both the driver and the rider, who don’t have to manipulate money anymore.
If you want to see, what is like riding an Uber cab, you can watch this video from Loic Lemeur who is the first Uber user in Paris. I can’t wait to try it one day. Folks, please, steal my wallet!!
She is right, even by following the best practices published by Google, you never know whether your app will perform the same everywhere until you actually test it on all the hardwares, all the resolutions and all the Android versions. This fragmentation is what makes programming on the Android platform so hard.
Yesterday I have thought about a possible solution that would rely on Crowdsourcing. This is how it works: Testers register to the platform by listing all the devices they can test the applications on. Then for each test, they would have to answer to a set of simple questions written by the developer(s). Of course, the platform will reward the testers in one way or another (or each developer would reward the testers in their own way). Hopefully some solutions like this one exist like The Beta Family. To be honest, it doesn’t seem like they have a lot of testers/developers relying on their service and there are certain things that I would do differently (like making sure that the beta can be downloaded immediately). So it would be interesting to rely on other type of platforms.
In fact there are other cloud based solutions, where different devices are available for your tests on the Cloud. Good examples of these are: Perfecto Mobile and Device Anywhere. I haven’t used one of these platforms yet, in fact I am not a test freak I just focus on testing on 3 different devices (3 completely different configurations, resolutions and Android versions) and I make sure to follow the best practices to deliver a high quality application. But if you have, please leave a comment and tell us what was your experience like.
Also, please drop comment if you happen to know other platforms/solutions to help solve that particular problem.
By this blog post, I would like to tell you how much I am grateful to you for putting all these classes online. First you taught me how to program on iOS from scratch and now you are teaching me AI and Machine Learning. I am so looking forward to following your different entrepreneurship courses to start the year off right.
It doesn’t matter why you are doing this, I just wanted to say: Thank you!
Turn off the TV, and start taking one or more of these free classes:
Seriously, turn it off!
Remember that last blog post where I talked about an Android event called Droidcon? The next one will take place in London and I am glad to announce that I have kindly been invited, as a Student, to attend this event.
This is very exciting, because:
I have never been in London before and it is one of the cities that I wished I could visit long long time ago.
Mobile development, especially with Android, is what I have been doing for the last couple of months. It is also what I am going to be focusing on in the future.
The quality of the speakers and the talks is very high!
The event will last for 2 days. Day 1 will be reserved for Barcamps where Android developers will gather to talk about different topics chosen by the attendees. Day 2 is a multi-tracked conference. I HATE (in the positive sense of the term) multi-tracked conferences, I wish I were able to split myself in two in order to be present at different rooms at the same time, but let’s top ranting about this. Let’s make a choice!
This is the program I will be following:
10:10 : I’ll start the day in Room 2 to attend the Wireframing Like a Pro session given by Greg Taylor. I think this is a great way to start the day. Wireframing is one of the most important things to consider when it comes to designing a new product. I don’t know whether Greg will talk about tools or processes, but in any case I will certainly learn a LOT from his talk!
10:45 : I think I’ll stay in Room 2 to watch Nick Butcher talk about Excellence in the Android User Experience. It is clear that a good user experience is crucial for the success of a Mobile application. Think about what all the top notch apps have in common? A good user experience, PERIOD! So hopefully, I’ll learn a bunch of tips form this talk that will help me build better and more successful applications. Finally, this talk is short enough to let me jump over another session when it’s finished.
11:35 : Room 2 again! Mustapha Isik will talk about building games for the Android platform. Back in 2003, I came into programming (for real) by building games in C++ (most of them were very simple though, Tetris, Snake, PacMan and a few failed attempts to build a RPG). Although I’m not into this anymore, I’m very curious about what it takes to build games for the Android platform. And who knows this talk may revive the passion that I had for building games!
12:20 : Let’s move to Room 1 now. Why? Because Mark Murphy himself (same as Chuck Norris but for Android instead of kicking asses), will talk about Traceview and MAT for Fun and Profit. MAT stands for Memory Analyser Tool, which is an Eclipse plugin that helps you reduce the memory consumption for your app and helps you find memory leaks! Traceview is an Android profiler that I tried to use before unsuccessfully as you can see in this StackOverflow question that I asked before. Wait! 130 talented developers took a look at my question and none of them dared to answer? Hopefully, I’ll be able to answer it myself at the end of this talk! Note also that this is where I hate multi-track conferences the most. Because during this talk I’ll be missing another talk about game programming on Android given by Yosi Taguri and a talk about Test Driving Android Apps using Roboeletric given by Joseph Moore from Pivotal Tracker. But hey, c’est la vie !
15:06 : I stay in Room 1 to attend a talk given by Richard Hyndmann about Android Market for Developers.
I just realized that the dice are already rolled here, since Room 1 hosts the longest talks in duration. However, there is one particular talk that I want to attend which is Massively Scalable C2DM with QoS and SLAs given by Dylan Boyd. So this is obviously about push notifications on the Android platform. I have been using C2DM for one of the projects that I have been working on and it works very well, but I still have a lot of questions about it and I hope this talk will help me answer them. So may be I’ll start moving back and forth from Room 1 to Room 4 starting from 15:40.
This will be very exciting, I can feel it! One last thing, I still don’t know where to sleep there! Do you, dear reader, have any good plan? Youth hostels are cheap but I have never experienced any before. The thing I am worried about is not having a good sleep because of roommates that come in at 4 AM or something. Generally I am not a heavy sleeper, I usually go to bed somewhere between 3 AM and 4 AM and wake up at 9 AM. But this time I want to sleep normal 8 hours in order to be fresh for the conference and for visiting London in good conditions!
Any good plan? Anyone looking for a room as well? May be we could take one BIG room at a youth hostel, for many droidcon attendees that are on a low budget as well, in order to reduce expenses?
Let met know, and I hope to see you soon at Droidcon UK 2011!
As an Android developer (yes for the last 3 months I have been doing a lot of Android development during my internship) there is one hell of a conference where I would love to go and that’s Droidcon. Droidcon, is typically a european based Android conference. Among all these Droidcons, the one happening in London on 6 & 7 of October 2011, is particularly interesting and well… intense!
Well, first let me tell you about the speakers:
Richard Hyndman from Google, who I saw last month in Paris where he talked about some good practices that every android developer
should must adopt.
Mark Murphy, enough said. This guy doesn’t need any presentation I guess, I mean that’s CommonsWare for god sake!
Again, check the entire list of speakers here.
The talks are also various, ranging from very technical presentations (Game development, managing concurrency on multi-core processors devices, unit testing your app) to more generalist presentations (running a private beta on the Android market, Security etc.). The program of the conference can be accessed here.
Of course, we can watch these sessions later or via streaming but nothing can replace a physical presence to the conference where you could actually meet and talk to other developers, exchange ideas, find some business opportunities etc.
To finish, the registration is not that expensive (150£) and I have actually never visited London, sounds like a great occasion to do it!
What do you think? Did you go to Droidcon London 2010, was it worth the commute/money?
Tell me about it!
In this blog post, I am going to continue what I started earlier. In other terms, I keep watching Ruby & Rails related conferences videos on Confreaks, and summarizing them on my blog. Today, I watched a very interesting talk given by Aaron Patterson (aka @tenderlove) called ZOMG Why is this code so slow?. Aaron is the father of Nokogiry, and he is basically the only one who is contributing both to Ruby and Rails (where he is the 4th top contributor)! He is also very fun to listen to, very comic but serious about the stuff he is talking about. (he actually reminds me of Scott Hanselman in the .NET world).
So the goal of this talk was to talk about the performance improvements that he made on ActiveRecord while rewriting ARel. Or no, wait! It was about the work he has done on ARel while improving the performances on ActiveRecord. Seems confusing? Actually, it is not. The goal of his talk was to explain how he fixed the performance issues on Rails 3.0. Rails 3.0 has (or had) performance issues? Turns out, yes! In fact, ActiveRecord was 5 times slower than Rails 2.3! Now things are doing better thanks to his work, but what did he do exactly? Let’s go into that! Summary starts…
Are the performance issues related to Ruby?
When should we make our code faster?
How do we know that it isn’t fast enough?
What is the basic thing that we need to do when working on performance?
But, what do we need to measure?
Post.find(id). The stack goes like this:
At somepoint, Aaron decided to focus on the 3 top level layers (from
log). He needed to run some benchmarks to know exactly where the performance issues were really occuring. We will get back to that later.
What are the two things that we should optimize for when dealing with performance?
What do we need to reduce in our to gain in performance?
Branching and looping.
Objects (memory consumption).
And turns out that when writing a clean code, the things to reduce are exactly the same. Therefore
Performant Code == Clean Code.
What tools do we have to run benchmarks?
Which gives the following results:
This has the ability to give us the information that the algorithm runs in a linear time.
We also have another tool for benchmarking which is called Minitest/benchmark.
What does minitest add to the game?
Minitest is nice in the sense where it allows us to assert that a given algorithm occurs within a certain class of complexity. For instance we could assert that an algorithms runs in linear time, if someone changes it in the way that it woul run in polynomial time then the assert would fail.
From the previous stack, where did the change happen?
After running benchmarks using the previous tools and after plotting the results, Aaron realized that the changes occured at the
What do we do then?
In Rails 2.3 2000 method calls of
Time#allocate were made for every 1000 iterations Vs 4000 in Rails 3.0 beta.
After fixing this, things were better but still 2 times slower.
What to do then?
Given that the
find_by_sql part didn’t really change between the two version of Rails, ARel was the one that needed to be improved!
First strategy: make superficial improvements!
Superficial improvements are useful when we have a limited domain and system knowledge. It allows us to see the results quickly, but we don’t get so much benefits for the time put into it. The superficial improvements that were made are the following:
Check for stack overflow.
Pushing a stack frame.
method?we can write an alias like this:
Rubyists tend to write the following code:
This could be instead written like this:
Benchmarking these two give the following result:
inject is slower than
map. The reason is that people are using it wrong, we should use
injectonly when one calculation depends on a previous one.
This is a better usage for
A lambda takes much more longer than a method call does. The reason is because the lambda needs to remember its context. So Aaron advises us to use lambda only if we care about using a lambda not just because it responds to call.
class_eval is about the same speed as the normal method.
define method is much longer. define method uses a
Explicit bloc parameters
– Symbol to Proc is much slower than just using a bloc. But in 1.9 that’s not true. So we need to know who we target (know your audience).
Here we have extra method calls so it should be avoided as much as possible. Can the caller cache?
At the end of these superficial improvements, the performance were better but not as good as they were on Rails 2.3. Aaron needed to go deeper!- After deeper inspections, he noticed that a lot of time was spent at
Class#new. A lof time at
garbage_collector which means that we create a lot of objects and throw them away.
– He did some Data Structure Analysis (using Graphviz), and he implemented a visitor pattern. The reason for using the visitor pattern is to be able to examine these data structures from the outside.
There is a clear solution.
Tests are numerous.
Public API is limited.
After 6 weeks of work, the results were encoruaging:
SQL statement generation was done at linear time.
ARel is now 2 times faster.
Adapter specific code is DRY.
He also implemented a new feature on ActiveRecord. Run the following :
Model.where("id == xxx").to_dot and admire the graph that is generated and that shows the relation between all the calls that are made :).
He finally finishes the talk by these two words of wisdom:
– We emphasize the art of code, but we should not forget the science.
– Learn the specific but embrace the generic.
I could not agree more!
As you can see, this talk was very informative and contained many tips about how we should approach performance problems. He introduced some benchmarking tools and explained the process by which he went through to make Rails 3.0 beta as fast as Rails 2.3.
I have to admit something, I have developed a new addiction over the past few days and it’s called confreaks! Confreaks is basically a repository for Ruby/Rails related conferences that are happening all over the world. I browsed the events page and I had a OMG moment thinking about the tremendous amount of content/information provided there. I need to watch them all, I said! Mind you, I just have 24 hours a day (I am sure it’s not true for everybody, some people are cheating with time I know it, I am sure about it, don’t try to convince me they’re not), so I’ll put some priority here and first watch those that could help improve my skills as a developer. But I also need to be wise here, I know myself better than anyone else, and I know that if I just watch a given presentation and don’t take notes somewhere, and if I don’t structure those notes, summarize them, write them and publish them then it’s not going to be that worthy and it would be like: Pisser dans un violon which, if you don’t speak french, means: Pissing into the wind. So this is what I will do here, I will write the information that I am taking from these presentations down and publish them here! Hopefully, other people will pass by and enjoy those notes as well…
No more talking, time to act! Let’s start with this presentation that I watched this morning called: *The Polite Programmer’s Guide to Ruby Etiquette* which was presented by Jim Weirich the father of Rake, Ed Summerfield and Chris Nelson. The PPGRE is about teaching people how to write Ruby code that doesn’t break other people’s code. Which is by the way very important, specially if you are starting writing a gem.
* When using hook methods make sure you are delegating to the previous implementation of the method.
* When you are using `method_missing` make sure you are implementing your own definition of `respond_to?` .
* Make sure you are not overriding the `method_missing` of the inner class, by making an alias of the `method_missing` definition.
* Alternatively, instead of putting method missing directly under the class that you are monkey patching, create your own module and put your `method_missing` method in there. In that case you are delegating up to the inheritance tree.
* Never test or call private methods (via `send`) unless you have a strong reason to do so.
Mark as private, the methods that are:
Implementation details, not interface.
Subject to change in the future.
* Put a `# :nodoc:` comment at the top of a private method definition, in order to tell rdoc not to generate documentation for this method.
There you go, that is all for this presentation. If you want to know more about PPGRE, I suggest you to go the official website.
Comme tout bon développeur Rails, il m’arrive assez souvent de regarder les excellents Railscasts de Ryan Bates et la première chose qu’on remarque dans sa façon de coder c’est son utilisation de raccourcis/macros qui lui permettent de générer des blocs de toutes sortes (form_for, if/else, each do etc.).
Ma première réaction par rapport à tout ça a été : need this! (productivité FTW). Seul petit problème, Ryan Bates utilise TextMate et a un Mac. Je me suis donc dirigé vers le site d’Apple pour…(Non j’ai pas fait ça, je repasserai plus tard pour l’excuse qui me fera acheter un Mac et puis j’ai pris un Nexus S récemment, ma carte de crédit est de mauvaise humeur :)). Je me suis donc demandé si mon bon vieux Vim ne pouvait pas, via une extension, reproduire ce genre de performances et j’ai très vite trouvé grâce à snipMate.
snipMate.vim aims to be an unobtrusive, concise vim script that implements some of TextMate’s snippets features in Vim. A snippet is a piece of often-typed text that you can insert into your document using a trigger word followed by a <tab>.
Donc en gros snipMate définit un certain nombre de raccourcis pour nous. A la base plusieurs langages sont pris en charge et chaque langage est défini dans un fichier de type *.snippets dans le répertoire:
Le seul problème c’est que l’écosystème de Rails n’était pas pris en charge. Après une petite recherche j’ai trouvé mon bonheur sur le repository GitHub de Mike Farmer, qui propose une collection de snippets pour snipMate dont: Ruby/Rails/Rspec/Cucumber/Shoulda etc.
Donc, si vous voulez être encore plus productif avec Vim en codant en Rails:
git clone https://github.com/scrooloose/snipmate-snippets.git
Ceci installera tous les snippets nécessaires dans le répertoire snippets de Vim. Et ça marche à la perfection :).
Preuve en images (cliquez pour agrandir):
Tadaa ! Prends ça dans ta GUI Textmate ! A moi la productivité maintenant, je vous laisse j’ai du code à écrire
Récemment, j’ai eu à faire face à un problème d’encodage des caractères accentués à deux niveaux:
Tous mes caractères accentués ne s’enregistraient pas correctement, mais cela était du à un simple problème de configuration au niveau du fichier de database.yml. En effet il fallait ajouter la ligne:
Une fois le premier point réglé, mes caractères accentués étaient bien enregistrés par contre j’obtenais le message suivant à chaque chargement de page:
incompatible character encodings: UTF-8 and ASCII-8BIT
Un rapide passage sur StackOverflow m’a mené vers l’article suivant où il est mentionné que le gem mysql n’est pas compatible avec l’encodage UTF-8. Et effectivement un passage au gem mysql2 a corrigé le problème !
1/ Ajout dans le Gemfile de la ligne:
2/ Mise à jour des paquets de gems:
3/ Changement de l’apdater dans le fichier database.yml:
Voilà donc petite note pour moi et pour les gens qui feront face à ce genre de problèmes.
Allez ne perdons pas de temps pour inaugurer ce blog et annonçons la nouvelle, nous sommes qualifiés à la finale du concours ID Mobile organisée par la société Alten. Qui ça nous ? Qu’est ce que ce concours ? Qu’est ce qu’on y gagne ? Je vais tenter de répondre à toutes vos interrogations…
Concours ID Mobile d’Alten ? Octobre dernier nous recevons un email interne à l’école, qui nous informe de l’organisation d’un concours de développement mobile. Le principe est simple, vous formez une équipe, vous réfléchissez à une idée/concept et vous la développez sur la plateforme mobile de votre choix !
Qu’est ce qu’on y gagne ? Celle là, je vous la fais en image..
Le premier prix était réellement le facteur WaW qui m’a fait bondir de ma chaise et qui m’a définitivement convaincu de participer. Etant passionné de technologies et d’entrepreneuriat, il est évident que je considère San Francisco comme une sorte de Mecque. Et c’est qu’en plus on y va pas juste en simple touristes mais pour assister, au choix, à la conférence Google IO ou MacWorld. Bref, le rêve! Les deux autres prix sont assez sympas aussi :).
Notre projet ? Bon c’est assez secret pour l’instant, on est un peu pudiques de ce côté là ! Mais je vais quand même vous donner un indice: elle permettrait de résoudre un gros problème que l’on rencontre surtout dans les grandes villes. Voilà, c’est dit ! Faites travailler votre imagination débordante, vous devriez pouvoir toucher dans le mille :). Dans tous les cas, j’en parlerai très certainement très bientôt de manière plus explicite !
Sur quelle plateforme ? Android.
Le futur ? On sera encadrés par notre parrain chez Alten et une journée Kick-Off sera organisée bientôt pour nous permettre de le rencontrer, de rencontrer les autres participants et de bénéficier d’une formation Scrum et également de développement mobile (au choix iOS ou Android).
Bref, que du bonheur en perspective mais aussi beaucoup beaucoup de travail qui nous attend si nous voulons allez loin dans ce concours et réaliser un bon produit !
Cela à priori, devrait bien se passer…
Je vous tiendrai au courant !