I am delighted to report that in the project I am currently working on, I get to play with a lot of smiley faces:
Hope that lightens up your day a little :)
(Yes, you guessed right: For every smiley page there is an equivalent with a frowny face, but sheesh, don't tell anyone ;))
When you look at the bottom of your GMail window, you'll notice links in the footer, cycling through more or less helpful tips as well as Google advertisements.
For years now, one of these links has been to the GMail Notifier for Mac:
Sadly though, this link to http://mail.google.com/mail/help/notifier/index.html (forwards to http://toolbar.google.com/gmail-helper) has, also for a long, long time now, been a not found error. As you can't open a bug report with Google, I've emailed the GMail service people about this before, but I guess dead links in production software are not on top of their todo list.
Ah well, maybe they google for "Gmail fail" sometimes and find the bug report this way ;)
Everybody knows Mozilla makes Firefox. But there is a lot more software at work here at Mozilla that you might not be aware of. For example: What happens when you go to getfirefox.com and click on the download button?
By clicking on the button, you ask our servers to send you a specific file, for example: Firefox 3.6.3, for Windows, in German. On a small website, the server would just fetch the file and hand it to you. But if you need to handle millions of downloads a day like we do, a single server can't handle it all by itself, so it gets more complicated. In order to provide you with downloads, updates, etc., as fast and conveniently as possible, Mozilla collaborates with a number of mirror providers that have volunteered to host Firefox and other downloads on our behalf, thus sharing the load of our numerous downloads between a number of servers all over the world.
For some years now, we have been running a bundle of software called "Bouncer" to handle our downloads for us.
Bouncer consists of of three components: The user-facing bounce script, an administrative interface called Tuxedo, and a mirror checker called Sentry.
First, the bounce script. It is the only component the "ordinary user" gets to interact with. It essentially does the following after you click on a download link:
But wait, there is more! How does Bouncer know what products are available, for what operating systems, and in what languages? That's where the admin interface comes in. We have a release engineering team who work hard every day to deliver the newest software versions to you in handy little packages. Previously, during every release, an engineer would manually tell Bouncer that a new version was available for download. But just last week, we improved this process by introducing a new interface to Bouncer, with a project called Tuxedo. The release engineering team can now, fully automatically, feed new versions into Bouncer at the time of release, with no manual intervention. With less time spent on repetitive tasks, we can spend more time making Firefox awesome.
Finally, the Sentry component is a script that periodically checks the health of our mirrors, and adjusts our settings accordingly. This is to ensure that a situation where you are forwarded to a mirror that is currently unavailable is very, very rare. So far, these mirror checks happen from Mozilla Headquarters, and therefore reflect the connectivity we get to the mirrors from here. In the future, we want to improve that by taking into account more how our users' connectivity is to the specific mirrors (for the geeks out there: Network proximity != geographical proximity), which has the potential to result in faster download times, less expenses for mirror providers, and general happiness.
As you can see, there are a lot of things happening behind the scenes before Firefox makes its way onto your computer at home, and we are constantly working on improving the way we are doing things. Plus, as always: Bouncer is completely open source, and we have a public bug tracker, so if you notice any problems or see room for improvement, make sure to let us know.
Photo credit: "directions", CC-by licensed by Phillie Casablanca.
After Apple and Microsoft have (finally!) publicly announced they are ready to pull the plug on Adobe Flash, the first makers of Flash webapps are starting to ditch it in favor of HTML5: As Techcrunch writes, Scribd, an online document hosting service, will focus its efforts on HTML5 from now on.
Scribd co-founder and chief technology officer Jared Friedman tells [Techcrunch]: “We are scrapping three years of Flash development and betting the company on HTML5 because we believe HTML5 is a dramatically better reading experience than Flash. Now any document can become a Web page.”
I am very pleased to hear that. Now that web standards are finally offering the kind of versatility modern web applications need, it is a fantastic development that companies are getting rid of the monster that is Flash. That's good for the user for so many reasons, and it's a great example of what HTML5 can really do.
Update: Ryan points out in the comments that Scribd has a demo document online of what this is going to look like. It's fantastic!
By the way: Another company I would like to see getting rid of Flash (in fact, I never understood why they used it in the first place) is slideshare. They are turning into a de-facto standard for posting presentation slides online, but as of yet, their main UI is solidly in Flash's claws. :(
On a growing number of projects at Mozilla, we use a tool called Hudson that runs a complete set of tests on the code with every check-in. The beauty of this is that if you accidentally break something, you (and everyone else) will know immediately, so you can fix it quickly. We also use a bunch of plugins with Hudson, one of which assigns points to every check-in: For example, if all tests pass, you get a positive number of points, or if you broke something, you get a negative score.
An innocent little commit of mine gained me a whopping -100 points (yes, that is minus 100) today.
How did that happen? The build broke badly, not because I wrote a pile of horrendous code, or because I didn't test before committing. In fact, I've made it a habit to commit like this:
./manage.py test && git push origin masterThis fun little one-liner will result in my code being pushed to the origin repository if and only if all tests pass.
So in my case, all tests passed locally, and then horribly broke once the server ran the tests again. After a little research, it turned out that when I deleted a now unneeded Python file, I did not remove its compiled cousin, the .pyc file, along with it. Sadly, this module was still imported somewhere else, and because Python still found the .pyc file locally, it did not mind the original .py file being gone, so all tests passed. On the server, however, with a completely clean environment, the file wasn't found and resulted in the failures of dozens of tests (all of which threw an ImportError).
What's the lesson? In the short term, I should wipe my .pyc files before running tests. One way to do that would be adding something like
find . -type f -name '*.pyc' | xargs rmto my ever-growing commit one-liner, but a more general solution might want to perform this inside the test running script. On the other hand, since that script is written in Python, some of the imports that could break have already been performed by the time the script runs.
In general, run your tests on as clean an environment as possible. While any useful test framework will take care of your database having a consistent state for every test run, you also need to ensure that you start with a plane baseline of your code -- especially if Hudson, the merciless butler, will rub it in your face if you don't ;) .
If you noticed an unexpected outage of my blog and all other sites on this web server, I apologize. This morning, I was greeted by a dead lighttpd web server and when restarting it, it decided to give me this error message instead:
2010-03-05 10:23:01: (network.c.529) SSL: error:00000000:lib(0):func(0):reason(0)
Luckily, a little bit of googling showed that this is a bug in lighttpd 1.4.26's SSL interface that can be fixed with this little workaround until a new version is released:
cd /tmp wget http://download.lighttpd.net/lighttpd/releases-1.4.x/lighttpd-1.4.26.tar.gz tar xzf lighttpd-1.4.26.tar.gz cd lighttpd-1.4.26 cd src rm network.c wget http://redmine.lighttpd.net/projects/lighttpd/repository/revisions/2716/raw/branches/lighttpd-1.4.x/src/network.c cd .. ./configure && make install
As you can see, the server is happily back up and running. Thanks to sekuritatea for the fix.
I know, I know. Technically, it's only a fail pet if a web site uses a nice little creature on an error page announcing unplanned down-time of the service.
That makes this ASCII cow from Craigslist not really a fail pet, but I find it a nice enough idea to blog it anyway:
This little fellow shows up on the 404 error page (i.e., any page that does not exist on craigslist.org, such as this one). While it is just taken from a well-known UNIX command, I like it a lot because it goes very well with the simplicity of craigslist itself, which is intentionally so much different than all the shiny "Web 2.0" applications.
Thanks for the hint, Jabba!
So, you have a bunch of .avi video files (from your cell phone, for example) that you'd like to combine into one (so you can upload the collection to YouTube)?
Here are two options on how to do this. The first one uses a tool from the transcode package:
avimerge -i one.avi two.avi three.avi -o output.aviavimerge is appropriately named, and if it works, it works well. Sometimes, however, it produces out-of-sync audio, which is kind of lame if people are actually, you know, talking in your videos.
Second method to the rescue: mencoder is part of the MPlayer family and can also concatenate avi files:
mencoder -oac copy -ovc copy one.avi two.avi three.avi -o output.aviNote: Both methods are lossless, as neither the video nor audio stream is re-encoded in any way, but they also require all input files to use the same stream formats. If you took the different videos with the same device though, that shouldn't be a problem.
Another addition to my ever-growing fail pet collection. Today: Neatorama, a website collecting everything, well, neat.
Their "fail pet" is an octopus, the "Neatokraken":
Fail whale, make room: You've got company.
A few days ago, a colleague of mine mentioned that the font I was using on my blog looked borderline ugly on Linux. Here's a screen shot:
As you can see, the uneven glyphs make it look goofy and certainly hard to read. The problem was that I used a font that seems to be present on many Mac and Windows computers, but was unavailable on my colleague's Linux box. His browser tried to substitute it with a different font -- with limited success.
So I decided to use a nifty little web feature called @font-face that allows me to define and embed my desired fonts into the website. Ideally, every browser on every platform will download the fonts I am using, and display my blog the way it is intended to look. The fonts I am using now are called Goudy Bookletter 1911 (for the headings) and Droid Serif (for the text).
I hope you like the new fonts and find them pleasant to read. If you notice any problems, however, please let me know!
Thanks for the hint, Lars, and thanks to all commenters for providing valuable feedback!