Podcasts app: another fiasco?
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.
Great Python Web Frameworks Showdown Aftermath
The Event
I finally got to processing video shoot at DneprPy #1 - The Great Python Web Frameworks Showdown. We tried to build a simple "wall blog" to compare Django, Pyramid and Flask and it was interesting and fun:
Here are the links to projects created for this showdown:
- Django - https://github.com/e0ne/showdown_wblog
- Pyramid - https://github.com/nskrypnik/dneprpy
- Flask - https://github.com/nimnull/flask-blog-sample
The Aftermath
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.
Format
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.
Technical Setup
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
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!
Chromebooks and iPads
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?
Let’s return back to 2010, the time when netbooks blossomed enjoying 34 million units in worldwide sales last year and analysts drawing all but wonderful future for this class of devices. This was also the year, when iPad was introduced. Remember it?

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”[1] 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. ↩
Netbooks: come and gone?
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
- powerful
- lightweight
- longer battery life
- inexpensive
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.
We could have declared the death of netbooks as a class right here, but let's take a look at Amazon's best selling laptops:
From hardware standpoint Chromebook is still a netbook and it remains to be seen whether it drag the idea of relatively underpowered, inexpensive cheap mobile computer into the future.
The Great Web Technology Showdown
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
- Shiny .Net
- Glamorous Ruby
- Furious Node.js
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.
And here is what we've got.
Python + Django
ASP.NET MVC
Java
Ruby on Rails
Node.js + Meteor
Building a team
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.
Here are some highlights:
- 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.
Fatal miscalculation for OnLive
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.
Wildcard DNS Service
xip.io - brilliant simple service for developers:
10.0.0.1.xip.io resolves to 10.0.0.1
www.10.0.0.1.xip.io resolves to 10.0.0.1
mysite.10.0.0.1.xip.io resolves to 10.0.0.1
foo.bar.10.0.0.1.xip.io resolves to 10.0.0.1