Simple Gallery - The next phase

Been thinking a lot about my Simple Gallery Management Project.
So far, it's been downloaded ~200 times (130 for version 2.0), and after implementing ~6 projects with it, I'm thinking about taking it to the next step, and making it an even simpler, more generic CMS.
This means generalizing the database, redoing the management portal into a cool, hierarchy-like content portal.

I'll still be using HTML/ JS/ PHP (For json API)/ MySQL as a platform, simply because the cheapest hosting services are under that platform. I could implement it with node.js and mongodb, but that would be overkill. Only when I implement a simple social network, then I might use these platforms - There are few services (Like dotcloud) which do node.js and mongodb hosting, and they are not meant for the SOHO customer requiring our services (myartichoke).

This also got me thinking - What about social networks? Does anyone really need to implement a social network anymore? The 2 major risers in the social network battlefield these days (instagram and pinterest) are less about social, and more about sharing and following, rather than full fledged social networks. This means that these social networks have the 'core' social features (contacts, feed, responses and likes) built into them, but not much more - Facebook and Google+ have a whole envelope of features which try to integrate the web into their sites.

Of course, all these networks also have RESTful web services, allowing for third party developers to integrate into their network as well. This has also become a common practice.

I've also considered multi tag support, but came to realize that I'm using this feature as a 'category' (news/ objects/ shows etc.) when implementing sites - That is why I'll probably change 'tags' to 'categories', and maybe add multi tag support later.

In scope as well is making the GUI a little more '2d' and consistent. Adding an integrated toolbar per item (Like twitter's), maybe convince my wife to design some buttons for me :))

I'll update soon, once the new version begins to show signs of life.

Big data, small code

Building a big data driven web application used to be a big thing. Relational databases, links tables, complicated queries and stored procedures...
Java containers, cache management, state - Big architecture, costing a lot of money, setup and development time.
Scaling also used to be a big thing. Databases needed to scale. Web servers needed to be synchronized. Whenever state or caching was applied, data integrity was a big, big issue.

With new servers like node.js and databases like mongodb, the web stack just got a whole lot simpler.
No need for complicated tables, queries.
IO is faster, without the need for object translations from tables to xmls to jsons or whatever.
And - More important - Indexing, multiple indexing and complex queries are supported as well.

Programming is also much, much simpler. Using dynamic language like javascript is much simpler than using Java. The whole setup is simple - Actually, these servers are extending javascript to be a native language, rather than living inside the browser sandbox. That way, your whole web application is written in one language.

Connectivity modules with other services (amazon, azure, mysql etc.) are available, and expanding rapidly.

My suggestion - Give it a shot in your next web application. If you like javascript like I do, this might be the smartest move you've done.

Edit: (Thanks to @lightpriest for pointing that out): Like all software solutions, you also need to make sure that this solution serves your problem better than 'old' web stack solutions. Read the other side here.

Reading time!

Part of my work week is dedicated to reading and learning.
Most of my reading these days is actually UI/ GUI related stuff, as we're closing a large project at work, and are going through some final GUI iterations.

The 'Little Big Details' blog is dedicated to small but neat and significant UI features found over the web/ mobile world.

This blog, of presentation expert Jan Schultink (Idea Transplant) contains all sorts of tips and notes about presentations, presentation design etc.

Wired's webmonkey has some neat notes in their UI/ UX section.

Here's a neat book by Google about web design.

Terry Martin's great blog got some great insights about design, tech and startups.

And, finally, some management stuff:
My company's COO is a big believer in Theory Of Constraints, and has started to implement this project management methodology in our company (Time To Know).

Basically, TOC works by identifying the project chain and building blocks, trying to deal with each building block as fast as you can (Which also means using as many resources in parallel on each building block to speed up the task), and daily reviews to find the critical (Longest) chain, and speed it up.

This method, though counter intuitive sometimes, has been implemented in the project I'm leading, with wonderful result. My team (~20 UI/ GUI/ Developers/ Testers) have sped up our project delivery times, management overhead is lower, and we're actually enjoying the process...

If you're managing a medium to large size project, my suggestion would be to give it a try. Though it takes some commitment, it seems to be working well for me... As well as reduce original cost in ~30%.

A link to our TOC consultancy company would be added to this post soon.

The New System Dilemma

...Or, how to roll out a new system and stay alive.

When rewriting a system/ subsystem, there's never a way to satisfy all your customers.
Usually, the organization expects you to rewrite everything to work exactly the way it worked before, with better performance and completely revamped UI/ GUI, at a fraction of the original system cost. Not to mention all the new features.

This sound absurd doesn't it? Well it doesn't. This is exactly what you've told them when asking for their approval to rewrite the whole thing.

So you're in a rough spot now.

You are expected to deliver the new system soon, the whole project is in a delay and not too stable anyway, and the organization still considers the old system, which is stable, mature and field proven (Though it costs a lot to maintain), as its best solution - Urgent market needs call for more personal to work on the current system, and your team is at risk to be 'vandalized' for those proposes.

In my 15 years of working in high tech, I've experienced many millions of dollars burn over such projects. Ambitious complete rewrites, sometimes trying to squeeze hundreds of work years in (Usually) tenth or less of the time.
It's always the same story: Take your best managers and engineers out of the daily cycle, isolate them and expect miracles to happen. Wait one, two years, and when the whole thing collapses, go into salvage mode, and try to incorporate as many components as you can in your products.
Sometimes the whole system goes to waste... Along with your best managers and engineers.

So what can you do to turn the tables?

Your first target should be 'setting your foot at the door'. This means deciding on your first customer, and focusing on the specific needs and goals of that one specific. Don't try to implement the whole organization's needs at once - Focus on your first rollout. This way you'll be able to roll out in baby steps, rather than go out with a bang... You'll also be able to minimize your risks, and gain the time to stabilize your new system. Set expectations with your first customer, let them know exactly what they're getting, and more important - what they're not getting. Which features they will miss, and why.

Your second target should be getting your organization's cooperation with the rollout. Some of those people might not have been involved with your 'incubator' project. Some of them might even think that the current system is much better. How do you get them to be on your side? Start involving them with the final decision making and scoping. Get their engagement by exposing all the cards in your deck. Partner with them, because you won't make it without them. This might even mean brushing up on your political skills...

Once your first, even if minor, rollout is successful, and the organization is on your side, you'll have enough breathing room to actually finish your project, and moving it on to the regular maintenance cycle.

Why go native?

... When you've got HTML5?
That's one question I get asked a lot in the past year.

When you've got so many cool new features in HTML5, and want to save development costs, is there any reason at all why your application should be native?
Why write for several platforms, go through the whole approval process (Difficult with Apple, less so with Android)?
Why maintain more than one environment, expert types, development environments? (And yes, I know about Flash Air Mobile, Aptana and Phonegap. And no, I don't consider them as 'native'.)

Well - There are several reasons why you would want to go native.

First reason to go native would be performance.
If you have long tables to present, large stream of information, graphics (Like dynamic maps), you might be better off native.

Second reason is better usage of your device's resources - Camera, GPS, accelerometer - These are all supported/ to be supported in html, but would not work as well as they would with native interface.

Third reason is UI conventions - When programming for a device, it's best to use its native components for UI. Simply put, your users would find it easier to set preferences and options, and learn the application in the visual language the device uses. HTML5 would never look better than a native app, especially in small mobile device screens.

Final reason would be control. You want your users to be focused in your application, rather than have four browser tabs in parallel. You might not want your users to be able to simply 'browse out' of your application (Without doing a proper cleanup...).

There's also a way to enjoy both worlds:
Applications can talk to their 'web view' programmatically: Actually, the only way to spawn a software keyboard in 'editable' divs (Like web based rich text editors do) was by wrapping your site with a small app, and have the javascript 'invoke' the keyboard via the app.
That means you can wrap a web view with a thin app, and that way get all the focus to your app.

So before you jump to HTML5, which is an obvious answer to which platform you choose, think it over a little bit - Maybe native is the way to go.

In the meantime, I'm really having fun exploring Xcode. It's not that bad, once you're used to the workflow. Of course, this isn't visual studio for windows phone (I consider VS to be the best IDE, with WP no exception), but for now - It's fine.

And, finally, here's an interesting article about a small, smart and very popular company. Instagr.am is one of the coolest companies I know. Click the link below to understand why.
What powers instagr.am

Go Xcode yourself

Got a new Macbook Air 13". It's a neat machine, and osx feels great, even for a windows fan like me.
Office for mac is cool, Webstorm is working, and now I'm brushing my unix skills (Installing mysql and activating the built in php and apache), and setting up my work environment.
The good ol' x40 will remain in the family, and go to my older brother.

Another thing I got a mac for was to begin learning iOS development.
Xcode is the official iOS IDE, and after a little bit of fiddling, I still haven't decided whether I really hate Objective-c, or really misunderstand the language.

The principal is supposed to be simple - Drag and drop stuff to the view, write the outlets (Bad name), write some code and then connect them (By doing lots of ctrl+clicking).

But the Objective-c language is, well, quite weird. And the whole concept is a little more complicated than windows phone IDE, FLEX, or even Android.

I will update more about what I've learned once I do some real programming (Some web request and more elaborate controls stuff) rather than just connecting a slider and button to a label...

In the meantime, I'm really, really enjoying the Air's form factor and great performance. Only minor disadvantage - 13" screen with 1440x900 display = Really really small fonts in some web sites.

From MVC to MVP to...

MVC used to be the buzzword for client development.
Implement the model, bind it to the controller and the view, or get a framework to do that for you, and there you have it - A fast client, connected to the server, great way to deliver your application.

Or is it?
I have never seen 'clean', by the book, MVC implementation. The controller and view logic gets mixed and messed up after a couple of iterations, binding makes manipulation of data formats hard, view business logic gets implemented in controller, controller code gets implemented in the view (Sometimes because of binding), and after a while the whole code gets impossible to understand and maintain.

So what do you do?
Find a simpler paradigm, which would work!
MVP says a simple thing:
- The model stays the same. Handle data and communicate with the server/ container/ host/ whatever.
- The presenter does all the work. Business Logic, View Logic, Validation, string formatting, whatever the user does NOT do interact with.
- The view handles GUI. There's no relation between the view and the model, the presenter takes care of that.

Now let's take this a bit further, and create inheritance based MVP component:
The View extents the presenter, which extends the model, et voila!

Now you have a simpler paradigm which could actually work and expend, you can rewrite or use different views (Different devices, for example) and have your factory create the client class according to the device...

As for frameworks - There are a lot of frameworks which would do the trick, though most of them do not use the inheritance paradigm. And anyway, I like to program my own frameworks, and use 3rd party frameworks to simplify specific infrastructural tasks (Like jax-rs for REST servlet implementation, or jQuery for DOM manipulation).

So next time you hear MVC/ MVP - try to see if the inheritance model suits you. You might be surprised how simple things could get...