Hot on HuffPost Tech:

See More Stories
Engadget for the iPhone: download the app now
AOL Tech

Latest Posts from Download Squad

iPhone App Review: Twitterrific exercises your EDGE connection and your patience

TwitterificSlick UI seems to be the norm for most 'big name' iPhone applications on the AppStore. Twitterrific easily gets the top spot in terms of having attractive UI and navigation. However, UI and usability are not synonymous. When I use my phone, I want to accomplish what I want to do quickly and easily. Unfortunately Twitterrific falls short in a few area which makes it one of the most frustrating apps to use on the iPhone.

Until recently, the only way for developers to test an iPhone application was to use the simulator. While it does a great job in allowing developers to see and interact with the app as they develop it, it doesn't show how the app performs in real-life situation.

There are two major differences between the simulator and the real iPhone that are at play here. One is the computer speed and the other internet connection speed. Even the slowest MacBook Air runs faster than the iPhone and thus any performance issue would be masked. Likewise with internet connection, there is no straightforward way to simulate the speed and latency of a EDGE connection and therefore any deficiency of the code in the app would not be exposed until the developers try it out on the real iPhone with spotty EDGE connection.

Twitterrific suffers from both of these problems. The scrolling performance of the message list is so jerky and slow that initially I thought there was something wrong with my iPhone. As I waited patiently for the list to scroll up and down, I also noticed that Twitterrific loads and re-loads every single user picture, even if it has previously been loaded. I stared at my iPhone in dis-belief because I could not comprehend how any sane developers would be as inefficient as that. My hunch that the reloading issue is tied to connection speed was confirmed last night when I got home and connected to the net via wi-fi. Both scrolling and picture reloading sped up because of the much faster connection I have at home.

Read more »

Dev Chair : iPhone SDK experience


The iPhone SDK has been out for couple of weeks now and I've been using it to develop an application for my work as a technology demonstrator. My experience thus far has been largely positive. I wasn't surprised by how well-made the SDK is, even at this beta stage. The amount of work involved in releasing any SDK, let alone one that is so tightly scrutinized, cannot be underestimated.

Consider that I am learning three new things simultaneously: programming in Objective-C, learning how to use Xcode, and what is available in the iPhone SDK, I am going to describe the whole experience instead of just confined to the SDK.

Read more »

Dev Chair : A geek solution to the writers strike

As the Writer's Strike continues into the end of January with no real end in sight, most people are running out of quality TV programs to watch. Heck, we're even running out of quality-less programs to watch. Unless you are a fan of reality shows such as Gladiator, there isn't much coming in the next month or so, if at all, for this rapidly evaporating season.

I think it is time we in the software industry step up to the plate and offer our help. With what we know about artificial intelligence (AI), genetic algorithms, and natural-language parsing, it should be possible to develop a software program where TV scripts are created based on previous episodes.

What we need are:
  • Characters in the series and their attributes (gender, personality, etc.)
  • Tons of previous scripts
  • The series formula, e.g. The new clue to solve the case between minutes 39 and 40 in Law & Order, or CSI.
  • A genetic algorithm that learns the characteristic of the series through all the existing episodes, e.g. how each character behaves, their favorite catchphrases, and how the general plot line evolves. For many shows, just the catchphrase would suffice.
  • A software bot to trawl the net for bizarre news as seed to generate new stories.
The scripts generated by this AI program would probably not very good at first -- but hey, neither was Seinfeld -- they might not make sense at all. But, after some teaching sessions by a human -- perhaps volunteers from the audience? It's all about crowd-sourcing these days, right? -- some reasonable scripts should result.

Granted this strategy would not work for proper drama like 24, Dexter, Weeds, etc. which all have major story arcs running through entire seasons but, it should work great for formulaic shows such as Law & Order, CSI, Numbers, Psych, where almost everything stays the same from episode to episode with only minor plot device differences in between.

How much effort would it take to develop this AI program? I don't have the faintest idea. I just suggest stuff, it's up to other people to handle the sticky details of implementation. I can imagine modifying an existing AI algorithm to accept TV scripts instead of whatever scientific research data, let it run on some beefy servers (may be run it as adistributed project like SETI@home? New TV shows are at least as important as finding aliens, maybe moreso.), and see what comes out at the other end.

Remember, this idea is hardly new. It has already been done with financial news by Thomson Financial as reported by Wired back in 2006. Is it such a big leap from news to formulaic drama?

Come on, doesn't this sound like a fantastic final year college project? Surely the prospect of getting your final assignment done and being the hero who breaks the Writer's Strike deadlock sounds appealing to someone?

More interesting question is: Which one is smarter? Law & Order, or an artificial intelligence program? With Fred Thompson dropping out of the presidential race, our money is on the AI.

Dev Chair : Do we want scientists or engineers?

Good computer science graduates do not make good software developers. Really, I mean it. But for the polar opposite reason that these two New York University computer science professors think.

When I was in high school my physics teacher once told us, "All physics experiments work. They just may not work the way you want them to."

This encapsulates neatly what software development is all about. On one hand, it is science. It is deterministic. Each programming language statement performs exactly as stated (baring bugs in the compiler, or the SDK, or the OS). On the other hand, software development is closer to engineering where years of experience allows a software developer to spot patterns in the model and apply them to build a system.

Unfortunately, just as in physics, computer science courses do not prepare students for what comes after graduation. Skills that are considered crucial in almost all commercial software projects are either not taught in college or are only touched upon. This disparity between the skills graduates possess and what the industry is looking for means it generally takes one to two years of working in real life project for a graduate to become fully trained.

Read more »

Dev Chair : Faster, better, cheaper with Agile?

Nokia N800
As NASA starts to wind down their Space Shuttle activity in the next three years, the space agency's effort to return to the Moon has been ramping up quietly in the background. With their new Orion/Ares space vehicle combination, crew automation will definitely be on the top of software priorities for NASA. But with a much smaller budget and shorter timescale than the last lunar attempt, would NASA and its contractors embrace new approaches and techniques so our tax dollars are better spent? Can Dan Goldin's "Faster, Better, Cheaper" approaches be finally achieved?

A couple of months ago I was fortunate enough to join ThoughtWorks, a company that advocates the use of Agile software development practices (Extreme Programming, Scrum, TDD, etc.) to bring business value to our customers. I have been using Agile practices on my previous project for over three years and it had proved to be highly successful. And ThoughtWorks' experience in this area proves that Agile can also be applied successfully on large enterprise software projects. But can Agile be used on a highly mission-critical software project such as the one for the Orion spacecraft?

Over ten years ago my first programming job was for small software company developing real-time, safety critical software for controlling railway trains. The work we did was the embodiment of the Waterfall model. The system requirements were collected and analyzed. The model was designed and validated. Then we mere programmers set out to write code to realize the model. Huge amount of unit tests and integration tests were created to make sure our code did what the model said it should do. All the while, the project manager kept track of our progress to ensure that, hopefully, we delivered the product on time and on budget.

At first glance, Agile sounds like a good fit with this type of project where requirements are generally very well defined and correctness are paramount. Short iteration and test-driven development will ensure features are delivered often and proved to be working by the unit tests. Continuous integration means there will be fewer surprises as multiple systems are joined up to work with together. The costs of requirement changes will be reduced and can be implemented quickly, rather than in the next version.

But would the world of safety /mission critical software development, dominated by engineers and scientists, be receptive to the less rigid world of Agile development? Would they feel that without the top down approach, its highly structured development process, and the tightly prescribed set of delivery artifacts, the project delivery cannot be guaranteed?

I would love to hear from people who have more recent experiences in this area of software development with regard to Agile. Is it being used, is it being used widely, and how effective it has been?

Dev Chair : What can green do for you?

Green

About a hundred years ago the Industrial Revolution transformed the lives of millions of people. The invention of steam power, telegraph, electricity and the like freed people from labor intensive jobs and let them spend their energy on improving living standards. The focus of the industrial revolution was on new mechanical inventions. It wasn't until the invention of the transistor in the 50's that the next phase of technological revolution was kicked into high gear. The advent of the electronic age further improved the mechanical machines and allowed us new methods of communications. Now, computer software dominates large aspect of our daily life.

The same pattern is happening with the environmental technology movement. As we move to a greener future, all our focus and efforts are directed towards mechanical improvements to existing technology, such as the use of fuel cells or bio-fuels over fossil fuel, or the replacement of environmentally harmful materials with bio-degradable materials.

Read more »

Mobile Minute: iPhone APIs are like life - they're full of compromises

Two weeks ago we saw the first wave of third party applications for the iPhone. But because Apple has yet to open up the device and provides an API (Application Programming Interface) for software developers, making third party applications right now is not for the faint hearted or even regular developers. A couple of weeks ago in MacBreak Weekly, Leo Laporte called for Apple to open up the iPhone immediately and he could not see any reasons preventing that happening. What Mr. Laporte, and most pundits, seems to imply is that providing an API is a straightforward process. Publish the API online and let the developers use it, right? If only it were that simple.

An API is a contract between the provider (Apple) and the consumer, who in this case is the software developers. As with any contract, once it is published, a level of trust is established between the provider and the consumer. This means the provider describes the functionality accessible by outsiders in the API, and that functionality will work as advertised. The consumer has to depend on the provider to keep their word so the consumer can develop applications base on that functionality.

But establishing an API also means restricting internal development freedom for the device. It is no longer simple to rework a particular function to provide better capability or performance without substantial testings to ensure the existing APIs are not broken. There are a few ways to deal with this situation.

Read more »

Dev Chair : Geeks are not Apple's target with the iPhone


This last Saturday I had the good fortune of being in the middle of a passionate debate between Roy Singham and another ThoughtWorker over iPhone vs. other smartphones. Roy argued that the iPhone is not the game changing device that most people claim it to be because his Nokia N95E90 smartphones can do more and better. The discussion was cut short due to scheduling pressure but it got me thinking, why do people lust after iPhone more than other smartphones? Is it because of the large touch screen? Is it because of the Safari browser? Is it because the iPhone is a video iPod and a cell phone? Or is it all just hype?

Read more »

Dev Chair : iPhone Safari and the rest of Web


iPhone day is upon us. Much has already been written about the iPhone despite the fact that only a handful of journalists have used it. One thing that is common among all reviews is the AT&T's EDGE network is slow. Perhaps it is faster now but EDGE is still no 3G.

Earlier this month at WWDC, Jobs told Apple's developers to develop web applications for the iPhone instead of releasing a SDK. Again, much had been written about how developers felt betrayed by Apple, and that web applications are not really applications at all. Despite all these resentments, a few iPhone only web sites have sprung up since WWDC. Unfortunately, none of them are particularly impressive or useful probably because no one has gotten their hands on a real iPhone yet, which kind of confirms what the developers feared; that web applications will not be as good as proper iPhone applications. There are exceptions, of course. NewsGator's online feed reader allows users to read their RSS feed via the web anywhere and sync with their desktop apps when they get home. Similarly, the latest version of Google Reader does the same.

With all the attention on iPhone only web apps, I think people are neglecting the regular web sites. Just because iPhone's Safari can render regular web sites fully and allows the users to navigate/zoom around the site with their fingers, it does not mean it provides the best user experience.

My prediction will be that as soon as all the new iPhone owners get home and start surfing to their favorite news site/blog/message board via EDGE connection, they will find that -- although they can do almost everything on that smaller screen -- it is not as easy as on the desktop computer. They will be disappointed and lots will be written on the web this weekend about how web surfing sucks on the iPhone using EDGE. And I will agree with them. Can you imagine loading and navigating cnet.com on the iPhone using EDGE?

So what can be done to improve the user experience? The solution is a concept that has existed ever since cell phones were able to connect to the internet; mobile versions of web sites. The idea of a stripped down version of the regular web site for a mobile phone is as old as HTML4/CSS2 themselves. Some of the best examples that I have used are Fandango, Twitter, Facebook, YouTube, and Vox. What is so good about specificly tailored mobile web sites? First, they are designed with cell phone in mind so the site is generally formatted to fit the narrower screens. Second, because of limited bandwidth mobile, they strip out all extraneous graphics, animations, AJAX menus and buttons, Flash, and the like. so the page will load quickly. Third, and the most important of all, because of the previous two reasons these sites always focus on what the users want to do on the site. Whether it is to find movie times on Fandango, updates your current thoughts/activities on Twitter or Facebook, or read/compose blog on Vox, these sites let users get there and do it quickly and pleasantly.

Some of the big players in the web are already there. Both Yahoo and Google have mobile version of their sites, allowing quick access to search, emails, and other features. BBC has a PDA version, so does CNN. As the battleground shifts from desktop to mobile computing, web sites need to start thinking about how their sites look on a restricted device (be it a UMPC, iPhone, etc.) because it is no longer just about providing content or services. It is about how easy the users can access these content or services.

My hope is that the iPhone will finally make web developers pay more attention to the mobile experience of their web sites. Even if iPhone 1.0 disappoints, at least other mobile web users will benefit from improved user experience.

Dev Chair : Why is Safari on Windows?

So Apple went and released Safari for Windows. It is interesting why Apple did this. Safari may be faster, as the Royal Steveness claimed, and provides a number of nice features that are not in IE7 or Firefox by default (e.g. Forms auto-fill and resizable text fields) but I am not sure it would get much traction in the long term once the novelty factor has worn off.

Steve Jobs also announced that 3rd party developers will get access to the iPhone via web apps. Traditionally, cell phone application development is 'hard'. Hard in the sense that, by nature, cell phone manufactures are not software companies, so either the software development kit (SDK) use lower level languages (C++, etc.), an unsupported developer community (compare with web or desktop development), or antiquated OS (Palm OS 5.x). Whereas web development has a much lower learning curve as well as much bigger pool of developers to pull from.

It is obvious, at least to me, that releasing Safari for Windows is primarily a move to open up the iPhone's development environment to the largest audience possible. If Apple were to actually make a proper SDK for the iPhone, it would mean the SDK would have to support the Cocoa framework on OS X, and either port Cocoa to Windows (possible), or use 3rd party framework for Windows (not likely, given how much Apple likes to be in control). Either way, I doubt this hypothetical SDK would be OS X only, and asking 3rd party developers to purchase a Mac just to develop for the iPhone would be the death keel that many have been predicting.

Read more »

Dev Chair : The Vista Tax

As regular computer user, I don't have much interest in migrating to Vista in the immediate future. I don't think it offers any great leap in usability or functionality over XP. UAC (User Access Control) is definitely much needed and will improve security overall but it can be annoying as hell for average users. Aero Glass UI is nice to look at but does nothing to actually let you work more... Read more »

Dev Chair : Rebooting the web

Two weeks ago at NAB, Microsoft announced their Flash competitor, Silverlight. At that time, I was like 'blah' about it, thinking it was just another reaction from Microsoft to Adobe. But when Microsoft elaborated more about their future web development strategy at MIX07 two days ago, I was stunned just like most Microsoft developers. CoreCLR, cross-platform .Net Framework, DLR, Silverlight,... Read more »

Dev Chair : Safety first

Many years ago, car manufacturers emphasized only new features to entice new buyers. Then some time in the early 90's car safety became important and car manufacturers put safety features top of the selling points for new model. I feel that right now Web 2.0 service providers are operating like those car manufacturers before the shift to car safety. Ever since the infant days of the internet,... Read more »

Dev Chair : Web 2.0 and future of desktop blogging clients

With all the new and shiny Web 2.0 applications coming out, one may easily be convinced that desktop applications are breathing their last breath. At least that's what Google would like you to think about Google Apps, and its chances against rival Microsoft Office. On the blogging front, most of the popular blogging systems (Blogger, Vox, TypePad, WordPress, etc.) have incorporated some degree... Read more »

Dev Chair : Create a Tumblr widget using Dashcode

Back in December Apple released a beta version of Dashcode, a programming environment which makes it easy to develop OS X Dashboard widgets. The problem with Dashcode is that there is not much information on how to use it available on the internet. Even the documentation that comes with Dashcode provides only the most basic information and does not currently link back to Dashboard documentation.... Read more »