Interesting description of setting up nearly identical devices with different software platforms. We get new devices every so often and the process of "unwrapping" the device and getting it up an running is an important part of overall experience.
Setting up a Chromebook and getting to work with the most up-to-date software takes about three minutes, maybe five if you’re slow. That’s not the case with the HP Stream 13, although it’s much improved over computers from just a few years ago.
Activating the online services is especially interesting:
How exactly is this simple or adding to the user experience? It isn’t. Instead, it’s a frustrating, convoluted process that belongs in 1999. Compare that to the free bits included with a Chromebook, which you get by being signed in to a Google account and clicking a link.
WebKit has become a de-facto standard for a HTML rendering engine with Gecko as the only viable competitor. It is good that there will be another player inevitably advocating for Web standards development and compatibility.
Podcasts app is probably most used app on my iPhone 4s. Despite not the most optimal design choices and reported issues, I've never been bitten by them hard enough to look for an alternative.
So, this morning I was kind of excited to learn that an updated Podcasts app has been released promising interesting goodies. I rushed to update hoping that at least some annoyances will go away. Unfortunately, not only them did...
Notice anything missing?
Can you see the reel-to-reel scrubber? Nope!
Can you tell how much time is left to play? Nope.
Can you seek 30 minutes into the podcast? Nope.
Can you change playback speed? Nope.
(Not) suprisingly on all of the screenshoots taken on iPhone 5 all necessary controls are present making for, I can only image, a great user experience.
I have three theories for why this happened, all of which are equally disturbing:
This release of Podcasts was sponsored by Downcast.
Apple wants to push me to upgrade to iPhone 5, which is less than perfect business practice.
This is just a bug. But the fact that it made it into release makes me want to question engineering practice.
I've already lost around 2 hours of podcast time today and this makes me sad.
This was the first event to be run in the way I envisioned for the showdowns and it was a perfect opportunity to validate some ideas and assumptions.
This time we've split all the talks into shorter segments to make sure things we are comparing are close to one another in time. Consider following. Overall each presentation was around hour and 20 minutes. Given that presentations follow the same structure talks about database access in different frameworks would be separated by 2 hours and 40 minutes - way to much for the audience to be able to meaningfully grasp differences and come to any conclusions. Segmented approach lets keep all the related points together making it easy to understand and evaluate them.
As we saw in the discussions after the event, segmented approach also calls for more orchestration with more or less detailed description of the overall format and the content of the segments upfront and short introductions before each segment.
Panel discussion with all the speakers after the main agenda also proven to be a valuable addition to the presentations.
For quick switching between the presenters we used TeamViewer in the following setup:
One laptop (the "director's laptop") was connected to the projector
From "director's laptop" a TeamViewer session was open to each of presenters' laptops
Resolution on all laptops should be set to projector's resolution. For most modern projectors 1024x768 should work fine
This setup allows for quick and seamless switching between the presenters from director's seat and it is exactly what's needed to run segmented presentations.
Another benefit of a setup like this may be in allowing people in the audience to connect to director's laptop via TeamViewer. Unfortunately, live coding and, for that matter, working with the code in an IDE or text editor does not look good on a project, so connecting via TeamViewer to director's lapton can be an option for those in the audience, who have seat further away from the stage.
Next event - Java IDEs Showdown on Dnipropetrovsk JUG meetup on March 21, 2013 - will also be run in segmented format with TeamViewer. Stay tuned for the announcement with details!
When I put together my thoughts about the death of netbooks I caught myself repeating the word underpowered more than probably allowed by the style guides. What’s interesting is that transition from underpowered devices to underserved users can explain why certain things happened and what the future might have for us.
Why Underpowered Netbooks Failed, but iPad Did Not?
1st generation iPad with 1GHz CPU and only 256Mb of RAM did not look that much impressive compared to an average netbook of that time equipped with 1.6 GHz CPU with as much as 1GB of RAM. How then could it have happened that 2010 was also a year when netbooks decline started and less powerful and more expensive iPads began their victorious march?
The reason for this turnover is that for netbooks insufficient overall performance translated into underserved users, but Apple managed to avoid this trap and instead created customer delight. And if there is a single explanation of how that happened it is in the word “apps”. Netbook users were given underpowered general purpose hardware to run traditional desktop applications on top of general purpose operating system and were lead to believe that they would be able to do that with the level of comfort they were used to with their heavy laptops. In retrospect it is easy (many things are easier in retrospect) to see why that would not fly, and why users would not like the sub par experience and would search for alternatives: tablets and later ultrabooks.
With custom operating system and, more importantly, apps iPad is able to provide superior experience on substantially less powerful hardware. It was only possible because both OS and the apps were carefully crafted to take most out of the underlying platform and not give the false promise that traditional software would work ok. Netbooks did not have any of that and initial “specification excitement” turned into mediocre daily experience.
So What About Chromebooks?
Chromebook, just like the iPad, does not pretend to be “just what you are used to, but better in some ways”. From day one its was marketed and seen as something different. Of course, the fact that Chromebooks have all the familiar laptop shape adds to the confusion, but we can be sure that people who get them do not simply go after cheaper general purpose PC laptops.
Another area where difference helps is applications. Because of the fact that the platform decidedly does not run applications from earlier era, developers are forced to create new applications, which specifically target the new device. Applications that cater for the strengths of the platform and workaround it’s weaknesses are what gives Chromebooks and Chrome OS at least a fighting chance against others for the future consumer computing.
That’s when you get excited about something after reading the specs, but before actually using it. ↩
For the last week I've been meaning to write about the death of netbooks. But as I tried to pull my thoughts together it was difficult to come to some sort of overarching conclusion.
My wife have been [almost] happily using netbook for more than 2 years now, but her complaints about unresponsiveness, when she opens more than several tabs in Firefox, seem to grow every day. Still she does not want to change it for a far superior (performance wise) 15" Dell as she likes the form factor and the fact that she does not have to be on power leash most of the time. As for me, I definitely liked the price when I bought it and looking back I do not see anything which would have given same return on investment. Why is that?
Throughout the history of portable computers we always wanted 4 things
longer battery life
Traditional laptops gravitated towards kind of powerful and relatively inexpensive and that was what was needed to have a "mobile office" and be able to easily setup a workplace, when you moved between locations. But times changed. As free WiFi in public places started becoming a norm, getting power for your laptop right where you needed became more problematic hence emphasizing drawback of short battery life. Also carrying around 3 kilos was not exactly the most pleasant exercise for a more mobile yet always connected lifestyle.
Netbooks were (yep, it is "were" not "are" since powerhouses of netbooks wave Asus and Acer stopped production on January 1, 2013) an interesting experiment to meet changing demands of a modern computer user. Cheap, lightweight yet underpowered computers with relatively long life on battery looked like a promising way into the future of mobile computing.
While the bet on mobility was right for netbooks the compromise on the performance went too far. Now many of those who need a mobile laptop would rather pay the price for a more powerful ultrabook or MacBook Air, and those who value mobility above all would opt-in for iPad.
Not long ago at Dnipro .Net User Group we've conducted first great showdown -- The Great Web Technology Showdown, where we gathered masters of 5 different web development platforms to show what it takes to build a sample app using their tools:
Time proven Java
Always young Python
The sample app was simple enough to be easily understood and actually build, but also featureful enough to showcase wide variety of tools in the arsenal of each platform. This time we set the goal of building a Blog Wall.
Blog Wall is a site, where anyone can register and post text messages (up to 1024 characters) and picture messages (image + description up to 256 characters). All posts are then shown on the main page along with author and date/time of the post.
Not long ago I was honored to presented for a second time on a great on-line conference IT-Brunch. This event was devoted to finding, hiring and keeping right professionals for your team. Here is the slidecast for my presentation (in Russian) where I try to draw analogies between software teams, FC Barcelona and army recruiting.
Job market for developers suffers from the lemon problem on both sides: there are not only many less competent developers, but also there are lots of crapy developer jobs. Every day makes it even harder for a good developer to find a decent job, and vice versa.
When you set out on a journey of building a team, first think about what you plan to achieve with this team. Winning school championship is very different from selling girl scout cookies: different goals, different teams, different approaches to building them.
Make team part of the hiring decision.
Hire for a specific position, not a generic job description.
Look for new team members in the company first. And, as a consequence, do not be afraid of letting people go to other teams.
Be honest on the interview: do not promise a candidate something, which will never come true, simply to get him in.
Perlman told his workers that when the service started they were not sure how many servers would be required and they ended up with around 8,000 servers on three-year leases as well as the networking resources to support the gear. On average the company had only about 2,000 users online at any one time so it was not able to turn a profit.
8,000 servers can burn your money very effectively. I wonder why they decided to scale well in advance of the actual demand instead of scaling with the demand.
Sad thing, though, is that despite all the cloud hype still the only cost-efficient way to get substantial server resources is to lease them with the longest billing cycle possible.
Google's new Chrome OS device - Chromebox.
I'm puzzled by lack of any description of any(!) use cases for this device for a user. Watch YouTube on TV? Hang out on Facebook? Why would I want to buy this computer?
If you like us use Mercurial for your source control and use Jenkins for continous integration and deployment, there is something you should know.
We use Mercurial tags to designate revisions suitable for some practical purposes. For example, we use tag 'qa' to mark a version of the system, which we think is worth deploying into our testing environment and running exetended set of tests. We also have a bunch of jobs on Jenkins, which are supposed to get latest 'qa' revision, build and deploy the system to testing environment.
Theoretical setup looks like following:
And one would think that since Mercurial's -r parameters work equally well with branches and tags, he is all set. And we apparently thought so.
Unfortunately, Mercurial's approach to tags and Jenkins' approach to checking for changes in repositories do not let the magic happen:
Tags in Mercurial are merely records in a version controlled file .hg/hgtags. So in order to see moved tag you have to have this file in local repository.
Jenkins uses a variation of hg incoming -r 'tag' to check for changes in repository. However, since in local .hg/hgtags tag points to the "old" revision, it thinks nothing has changed for that tag-branch.
Simple (although not excatly most efficient) trick that works is wiping the workspace before build. There is a plugin, which can make this a part of a build job: Workspace Cleanup Plugin. Do not forget to mark this checkbox in job configuration:
This solutions has an obvious drawback of discarding any artifacts from previous build, which might save time during the next build and cloning the entire repository from the source control each time instead of just a bunch of changes.
For us I figured we are not running these 'qa' builds too often and the codebase is not too big yet, so we've settled with this workaround for the time being.
Those little switches. Using the APIs from Facebook, Twitter, Foursquare, and other services, Instagram lets you share from one single screen. Brilliant. I had never seen photo-sharing across services stripped down so simply before.