Fishpool

To content | To menu | To search

Tag - software

Entries feed - Comments feed

Thursday 9 May 2013

HTC One - an unreview, or what could be done better?

Finland is a funny market. Home of Nokia, most interesting devices take a while to actually become available here. Three years ago, I got my Nexus One by help from a colleague based in UK. It served me well - while it had always been pretty short on memory and for a long time had not been too impressive in terms of speed, it had a nice form factor and, even by today's standards, a fairly good display. However, I had been planning to swap to something more up to date for a while.

The Nexus 4, however, still isn't available here. Sure, at times a local retailer might have a few units with a pretty unattractive price, but the value proposition Google gave for the device is unreachable, since they will not deliver it from Germany, France, or UK to Finland. So much for the unified trade region of the European Union..

13050001_1 So, when I first heard of the HTC One, I had not picked up anything as a new device. I had considered a Galaxy S III, but I can not warm up to the imitation-chrome-rimmed plastic design Samsung is so fond of. In sharp contrast to that massive sales hit of the Android world (behind only the iPhone in sales figures), HTC One is a gorgeous design item. Enough has been written about its surface features, I see no point adding to that conversation. To my eye, HTC One wins the physical aesthetics crown among current phones, with the iPhone 5 and Nokia's Lumia 720 coming behind it. Each represents a very different philosophy and executes the details well. Anyway, I'm more of an Android guy, so even if One wasn't so gorgeous, I would not pick an iPhone or Lumia for myself.

But Finland isn't among the first markets for HTC either - heck, often it isn't an early market even for Nokia. In addition, One has suffered several delays, just barely making it to some markets ahead of the Samsung Galaxy S4, which must be its worst rival. So, especially since I managed to crack the Nexus One's screen to an unusable state, I had to resort to foreign help again - always a bit of a gamble with even with unlocked phones, due to the network differences. Since I couldn't locate a device in Germany, it was time to look what UK could deliver. And deliver it did - through Ebay, I received an untouched, still-in-retail-wraps HTC One last Friday.

I have to say it's just as beautiful in real life as it was in pictures. The finish is exquisite, with the aluminum, glass and polycarbonate seamlessly fused together. I would have happily traded 10 grams more mass and a millimeter in thickness for a more powerful battery, which I'm certain is the weakest part of the device, but it's not difficult to come up with a strategy that will take the device through my regular working day. As most reviews have concluded, it's at the top of Android models, if not of all smartphones.

But what of the un-review? Here are the things HTC has failed to do a good job with, all in the software installed on the device, as noted over one week of use. Where I've figured out a workaround, that's noted, too.

  • The Power Saver - yes, it has one built in. However, the way it's implemented (as an always-there checkbox at the top of the Notifications panel), it obstructs Android 4.1 from presenting the expanding notifications (which are present only for the topmost item). Those notifications are very useful. So, long-tap on the power saver option until an App Info pop-up appears. Through that, you can kill the Power Saver to recover the notification menu. For power saving itself, I use Llama profiles and a few events I've come up with over time.
  • The Calendar - several dealbreaker presentation problems, such as no weekday info in the daily view, no event labels in the weekly and monthly views (despite plentiful resolution to display small type on the Full HD 4.7" screen) and terribly confusing multi-calendar display options. I replaced it with Google's own Calendar app, hiding the built-in tool. They'll show the same calendars and this swap in no way prevents the lock screen and BlinkFeed from continuing to show calendar entries.
  • The keyboard's auto-complete and auto-correct is really irritating, including that hitting space will complete words but not insert the space. Replaced with SwiftKey, which is a far more competent solution anyway - but I might not have done it, had the keyboard been just that tiny little bit more finished.
  • The Share menu in HTC's own apps, including the browser. Limited to showing only four sharing options, among which HTC's own service and the not-so-great Mail app, all of the tools I use to share content (most notably GMail and Buffer) require extra taps. Chrome does not suffer from the same issue, though, so for browsing, this is easily bypassed. Too bad, because the HTC-customized stock browser is otherwise quite competent, slightly faster, and supports Flash for the few situations where that still is valuable.
  • That Mail app. Sure, it will connect to various mail servers including Exchange and private IMAP servers, but it's not nearly as polished as the GMail app, and all my mail accounts are backed by GMail anyway. This would not be a big deal, except for..
  • The lock screen is able to show weather, upcoming calendar entries, incoming SMS messages and the latest mail headlines - except, it will show the latter from the Mail app only, not from GMail. D'oh. Naturally, some might prefer to not show that potentially sensitive data on the lock screen, but I'd prefer the convenience, if it worked.

While overall I still prefer stock Android to these manufacturer customizations, HTC has improved on a couple of points. BlinkFeed is a nice presentation of news, Facebook and Twitter streams without leading to any undesirable duplication of work so common in these aggregation apps, the People browser that replaces both Android's Contacts app and the stock dialer is pretty good, though it takes some getting used to, and the camera application is a good use of the unique capabilities of the device. Of the major flaws, only the Mail/lock screen issue is something I have not found a workaround for, and it's a stretch to call that issue major. Nonetheless, I hope and expect HTC to deliver an update (perhaps along with Android 4.2) that would address these issues, many of which have been already noted by others, too.

Oh, and the camera? Its 4MP "UltraPixel" direction certainly sets the device apart from the competition. I have not done comprehensive side-by-side tests of it, but it does have good low-light performance (especially considering others, including the Lumia 920, use much longer exposure times and thus suffer from more motion blur, even if their image stabilization were able to eliminate camera shake). Perhaps the color balance could be slightly better. As for the resolution, it's certainly enough for online use, though won't leave much room for crops. Considering no mobile camera apart from the already-extinct PureView 808 can compete with a zoom-enabled pocket camera, let along a DSLR, I think the camera performs where most consumers would need it to. I hope HTC's gamble will pay off, and those same consumers won't be misled by the megapixel wars.

The other stand-out feature, unmatched sound output certainly stands out as well. This is the first mobile device capable of putting out a decent audio stream that I've tried. I doubt music will ever truly sound good at this scale, but at least its recognizable even from a distance. Most importantly, voice output comes clear and loud, so this is by far the best speakerphone ever made. If there's anything I can fault it with, it's this - even the lowest volume setting is sufficiently loud to carry over in a quiet room in a way that might bother other people nearby. I'd like one more setting below it, but headphones solve this with minimal inconvenience.

Wednesday 12 December 2012

A marriage of NoSQL, reporting and analytics

Earlier today, I mentioned querymongo.com in a tweet that fired off a chat covering various database-related topics each worth a blog post of their own, some of which I've written about here before:

One response in particular stood out as something I want to cover in a bit more detail that will fit in a Tweet:

While it's fair to say I don't think MongoDB's query syntax is pretty in the best of circumstances, I do agree that at times, given the right kind of other tools your dev team is used to (such as, when you're developing in a JavaScript-heavy HTML5 + Node.js environment) and the application's context is one where objects are only semi-structured, it can be a very good fit as the online database solution. However, as I was alluding to in the original tweet and expounded on in its follow-ups, it's an absolute nightmare to try to use MongoDB as the source for any kind of reporting, and most applications need to provide reporting at some point. When you get there, you will have three choices:

  1. Drive yourselves crazy by trying to report from MongoDB, using Mongo's own query tools.
  2. Push off reporting to a 3rd party service (which can be a very, very good idea, but difficult to retrofit to contain all of your original data, too).
  3. Replicate the structured part of your database to another DBMS where you can do SQL or something very SQL-like, including reasonably accessible aggregations and joins.

The third option will unfortunately come with the cost of having to maintain two systems and making sure that all data and changes are replicated. If you do decide to go that route, please do yourself a favor and pick a system designed for reporting, instead of an OLTP system that can simply do reporting, when pushed to do so. Yes, that latter category includes both Postgres and MySQL - both quite capable as OLTP systems, but you already decided to do that using MongoDB, didn't you?

Most reporting tasks are much better managed using a columnar, analytics-oriented database engine optimized for aggregations. Many have spawned in the last half a decade or so: Vertica, Greenplum, Infobright, ParAccel, and so on. It used to be that choosing to use one might be either complicated or expensive (though I'm on record saying Infobright's open source version is quite usable), but since last week's Amazon conference and its announcements, there's a new player on the field: Amazon Redshift, apparently built on top of ParAccel, priced at $1000/TB/year. Though I've yet to have a chance to participate in its beta program and put it through its paces, I think it's pretty safe to say it's a tectonic shift on the reporting databases market as big or bigger as the original Elastic Compute Cloud was to hosting solutions. Frankly, you'd be crazy not to use it.

Now, reporting is reporting, and many analytical questions businesses need to solve today really can't be expressed with any sort of database query language. My own start-up, Metrify.io is working on a few of those problems, providing cloud-based predictive tools to decide how to serve customers before there's hard data what kind of customers they are. We back this with a wide array of in-memory and on-disk tools which I hope to describe in more detail at a later stage. From a practical "what should you do" point of view though -- unless you're also working on an analytics solution, leave those questions to someone who's focused on that, turn to SaaS services and spend your own time on your business instead.

Thursday 13 October 2011

Where the chips fall - platform dominator for 2012

It's been about a year since I put my prognosis skills on the line and tried to predict where technology and consumer products are heading. Since today is National Fail Day in Finland, perhaps it's time to try again. Lets see how right or wrong I end up being.

Last year I noted a couple of things about mobile platforms and of the software environments best suited for creating apps on them. While this year has seen a lot of development on those fronts, little of it has been in surprising directions. HTML5 is coming, but not here yet. If WebGL and Intel's River Trail project were supported by the Big Three (IE, Firefox and WebKit, ie Safari/Chrome), that'd make an amazing game platform - but at least the latter is research-only at this point, and IE9 isn't going to support either. In the meantime, Adobe finished Flash 11, which now has hardware-accelerated 3D in addition to a pretty good software runtime, and, after only 10 days out, already has 42% reach for consumer browsers (at least judging by stats on habbo.com). Like I've said a long time, Flash gets a lot of undeserved crap due to the adware content created on it. We won't get rid of that by changing tech, and platforms should be judged by their capabilities in the hands of good developers, not by mediocrity. And, as far as mobile goes, the trend continues -- iPhone and Android battle it out, now also in courts as well as in consumer markets, while everything else falls under the wagon. If you're creating an app -- do it either with a cross-platform native toolchain, or with HTML5. If you're doing a game, do it with Unity or Flash, and build a native app out of it for mobile.

The interesting thing, to me, is playing out on the Internet. Google+ came out as a very nice product with well-balanced feature set, but (fairly predicably, though I was rooting for it) failed to catch the early adopter fancy for long enough to displace Facebook in any niche. Facebook, on the other hand, scared (or is going to scare) 40% of their audience by announcing Timeline (eek, privacy invasion!). Brilliant move -- you can't succeed today without taking such leaps that nearly half of your audience will be opposed to them, at least initially. Smaller changes simply aren't meaningful enough.

So, I'm betting on Facebook. I'd also guess that once they get Facebook Credits working outside of the Canvas, they're going to demand that any app using Facebook Connect log-ins will accept Credits for payment. I'd hazard a guess they're even going to demand FB Credits exclusivity. They'll fail the latter demand, but that won't stop them from trying it. Having your app's/game's social publishing automatically done by Facebook simply by feeding them events, and not having to think about which ones are useful to publish, is just such a big time saver for a developer, no one will want to miss out on it.

Not even Zynga. They're doing this destination-site, we're-not-gonna-play-inside-Facebook-anymore strategy, but continue to use Facebook Connect for log-ins. That's not because FB Connect is so much more convenient than own username and password (though it is), but because even they can't afford to let go of the "free" access to people's social network. That's the power of Timeline and the new, extended Graph API.

The chips are still in the air. When they fall, I think Facebook will be stronger than ever, but strong enough to displace the "rest of the Internet"? No. As a developer, I want to push Facebook the data for in-game activities, because that saves me time doing the same thing myself. As a publisher, I'm unsure I want Facebook to have all that info, exploiting them for their purposes, risking my own ability to run a business. As a consumer, it makes me uneasy that they have all that info about me, and while I can access and control quite a lot of it, I can't know what they're using it for. I don't think that unease will be enough to stop me or most other consumers from feeding them even more data of our lives, likes and activities. Still, they're only successful doing this as long as they don't try to become a gatekeeper to the net - nor do they need to do that, since they get the data they want without exerting control over my behavior. Trying to fight against that trend is going to be a losing strategy for most of us - possibly even for Google. Apple and Microsoft won't need to fight it, because they're happy enough, for now at least, to simply work with Facebook.

Tuesday 21 June 2011

On software and design, vocabularies and processes

Having recently witnessed the powerful effect establishing a robust vocabulary has on the process of design, and seeing today the announcement of the oft-delayed Nokia N9 finally hit TechMeme front page, I again thought about the common misconceptions of creating software products. It's been a while since I posted anything here, and this is as good a time as any to do a basics refresher.

A typical axis of argument sets software engineering somewhere between manufacturing and design. I, among many others, have for years argued that the relationship of software to physical manufacturing almost non-existent. This is because while the development process for a new physical product, like any involving new creation, starts with a design phase, the creation of a specification (typically in the hundreds of pages) is where the manufacturing really only begins. The job of the spec is to outline how to make the fully-designed product in volume. In comparison, by the time a software product is fully-designed and ready to start volume production, there is no work left - computers can copy the final bits forever without a spec. There's more to that argument, but that's the short version. Creating software is the design part of a product development process.

So, goes the line of thinking, if software is design, then it must be right to always begin a software project from zero. After all, all designs start from a blank sheet of paper, right? At least, all visual designs do... No good comes from drawing on top of something else.

If this truly was the case, what do you think they teach in art schools, architecture departments, and so on? Technique? For sure, but if that was all there was, we'd still be in the artesan phase of creation. History? Yes, but not only that. An important part of the history and theory of design is establishing lineage, schools of thought, and vocabularies which can serve as a reference for things to come. All truly new, truly great things build on prior art, and not just on the surface, but by having been deeply affected by the learning collected while creating all which came before them.

Not having actually studied art, I have only a vague idea of how complex these vocabularies are, and this is an area where a Google search isn't going to be helpful, as it only brings up the glossaries of a few dozen to at most a hundred basic terms of any design profession. This is not even the beginning for a real vocabulary, since those describe to a great detail the relationships of the concepts, ways of using them together, examples of prior use, and so on. However, even from this rather precarious position, I will hazard a statement which might offend some:

Software design, in terms of the vocabulary required for state of the art, is more complex than any other field of design by an order of magnitude or more. The practical implication of this is that no new software of value can be created from a "blank sheet of paper".

This will require some explanation. Let's tackle that magnitude thing first.

Any complete software system, such as that running within the smart phone in your pocket, measures in the tens, if not hundreds of millions of lines of code. LOC is not a great measurement of software complexity, but there you have it. In terms of other, more vocabulary related measurements, the same system will consist of hundreds of thousands of classes, function points, API calls, or other externally-referable items. Their relationships and dependencies to each other typically grow super-linearly, or faster than the total number of items.

By comparison, the most complex designs in any other field are dwarfed. Yes, a modern fighter jet may have design specs of hundreds of thousands of pages, and individual parts where the specs for the part only are as complex as any you've seen. Yes, a cruise ship, when accounting for all the mechanical, logistic and customer facing functions together may be of similar complexity. And yes, a skyscraper design blueprints are of immense complexity, where no one person really can understand all of it. However, a huge part of these specs, too, is software! Counting software out of those designs, a completely different picture emerges.

None of these designs would be possible without reusing prior work, components, designs, mechanisms and customs created for their predecessors. Such is the case for software, too. The components of software design are the immense collections of libraries and subsystems already tested in the field by other software products. Why, then, do we so often approach software product development as if we could start from scratch?

Why was it that the N9 reminded me of this? Well, if stories and personal experiences are to be trusted, it seems that during the process of creating it, Nokia appears to have "started over" at least two or three times. And that just during the creation of one product.. As a result, it's completely different, both from a user as well as a developer standpoint to the four devices which preceded it in the same product line, and two (three?) years late from it original schedule. Of course, they did not scratch everything every time, otherwise it would never have finished at all. But this, and Nokia's recent history, should serve as a powerful lesson to us all: ignoring what has already been created, building from a blank sheet instead, is a recipe for delay and financial disaster.

Software is design. Design needs robust vocabulary and the processes to use them well, if it is to create something successful.