$100,000 in Cloud Platform credit for 1 year
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.
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
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?
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” 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.
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.
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.
Ruby on Rails
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.
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.
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
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?
Good news, however, is that you can use rollApp to run desktop applications on Chromebox.
Mixed content is not allowed with WebSockets; that is, you can no longer open a connection to a non-secure WebSocket server from secure content.
Other browsers still allow this.
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.
Jenkins developers already know about this issue: Support tags instead of branches
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.
Every time you touch your finger to your iPhone’s display, the OS literally goes crazy: “Someone’s touching us! Someone’s touching us! Stop everything else you’re doing, someone’s touching us!”
Good code is not elaborate code. Good code is what makes a good product.
Success in software development is determined by users willing to use you product, not from fellow developers, who praise your code, alas.
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.
The keywords are: sharing and simple.
Recently I presented at IT Brunch online conference with a talk about experience of my team doing part time agile development. Here are some highlights:
- On a personal productivity level do not mix narrow focus tasks like fixing a bug in code with wide focus activities like contemplating about future of technology in your niche.
- If your team is distributed in time, but not in space, which is not unusual for a team of parttimers or freelancers, give yoursleves a time to get together and just talk (you can eat your lunches at that time too).
- It’s hard enough to do even one big thing, let alone two. Don’t try to focus your effort on several major features.
- General management practices still work: if you are a manager, have one-on-ones with your team members.
- Do not neglect up front design and specification development. There are situations, when it’s easier to try to foresee a problem, than try to resolve it.
There was a questions on where to get more information about one-on-one meetings. I suggest you start with One-on-Ones: The Single Most Effective Management Tool and check out other podcasts on this topic from Manager Tools.
Yesterday Amazon announced immediate availability of Route 53 (their DNS service) tools in AWS Management Console, which is great news for all the AWS users. But it also bad news to services like Interstate53, which I was using to manage DNS records hosted on Amazon, because it immediately renders them irrelevant. It is good time to remind ourselves how addon development is not exactly the best spot for software vendors and how in some cases you can still compete against the platform vendor by having significant value add.
You can not make washing machine do your laundry for you by saying you are busy.
Merlin Mann, Back to Work #33
Recently I've got a question from a colleague: "Have you had a situation when somebody was trying to manipulate you or your behavior? What can be the best way to stop/resist this sort of attitude? Stop any interaction with the person?" From my perspective manipulation, generally, has to aspects to it:
- Other person wants you to do something (which is not necessarily a bad thing).
- She wants to make you do it in a sort of "covert" way, which I would generally call a bad thing in professional environment.
When it comes to response to manipulation, all things being equal, I would have a conversation with a person saying something along the lines of "Hey, I've noticed that you try to trick me into something and don't like you doing that. If you need something from me, let's discuss, but don't try to trick me."
This kind of feedback serves two purposes: (a) letting other party know that you've noticed manipulation and don't like it (who does?); (b) showing a better way to do business with you. If a case is not helpless, this should help.
What do you do when somebody tries to manipulate you?