New stack, full stack.

In the past month I've been busy rebuilding the LightApp stack from scratch.
LightApp is a very cool startup in the industrial energy management field.
The product's essence is collecting data from various sources (Sensors, meters, production databases) of huge factories and analysing it to find ways to improve their effectiveness and reduce their costs and carbon footprint.
Previous product was built over LAMP stack (Linux/Apache/PHP/MySql), using the webii PHP framework, and had a lot of limitations - One example was heavy relying on SQL to perform statistical analysis, which was costly and shown poor performance and response time.

We've decided to rebuild the client (Not the database) with node.js, and after less than a month (We're a team of two) we've managed to almost completely finish our rewrite.
For UI we've decided to use bootstrap and amcharts, and manage the data ourselves (Rather than use a framework like angular or backbone).
Over the server side, express was used for main routing, mysql for database connection, and nunjucks for server side HTML.

The application doesn't have too many end users (Expecting few hundreds during 2014), but each user is performing heavy statistical analysis operations (Like a distribution of hourly data per category over a period of 6 months) - Which should be done really fast, and it is. Querying large data sets and crunching them in node is amazingly fast, but in the near future we will move our data to mongo, which can perform this analysis even faster.

Developing the whole stack in Javascript is fun - Though the language has a lot of limitations, it's fun to use, easy to debug and test, and, for our use, proves to be cost effective. Node.js asynchronous programming mode takes some time getting used to, but if you've dealt with AJAX on the client side, you'll be quite familiar with it.

I would highly recommend every programmer to try writing a full stack JS application. It's amazing how Javascript has evolved in the recent years.

Rewrite your Product, and live to tell about it

In every organisation life, there comes a time when its product is due to a big overhaul.
From dated GUI to dying Database, a Business Logic layer that's filled with patches, or even personal changes ('The only girl that knew that code has left...').
So now the company gives you, her beloved manager, a clean slate to rewrite the product.

Supposedly a dream come true, right?
In a past post, I've discussed the new system dilemma, a situation where you're already knee deep inside the rewrite, and pressure is rising.

This post should help you avoid that terrible situation.

The most important rule when writing a product from scratch is deciding what it's NOT going to do in phase one (See time frame in the second rule). Trying to match all the features the old system supports (Sometimes while it's still being developed by tier 4) will result in an endless effort.
Focus, and be transparent with what you'll deliver and what you won't. Put an emphasis on what your rewrite brings to the table that the old stack doesn't.

The second most important rule is DON'T LINGER. 3 months. Show something (Even a playable mockup) after 1 month. Show progress every week.
Three months is a long time, and mind that things can change, but it's a short enough time frame that things won't turn completely around.

When phase one is near the end, you can "Let the company in" and plan the next stages.

Focus and Agility bring results. Go for it!

Draw me a unicorn

The recent talk about unicorns - Startups which passed the 1 Billion dollar valuation - Have started a goose chase by many VCs. Series A VCs are no longer interested in companies which would give them 5x return (ie - be part of a 5 Million $ investment, and receive 25 Million as part of a company's exit), but they need more than that.
So VCs are no longer looking for teams which can build 50 Million businesses, but a billion dollar business.

While that might make sense financial wise, it may actually kill the whole VC business, which is already dying. Super angles and private equity investors are already taking their place not just in seed but also in series A.
Startups might just be better like that.

YULES.CO is up - Check it out!

Got a new self promotion website.
Currently quite generic, but much more coming soon:
A more visual timeline of my career, and blog might also move there (though I really like the advantages of the Blogger platform).

Come visit me at www.yules.co. More to come soon!

Tunnel vision

During the life cycle of a 'live' system, things tend to break.
Sometimes because you've missed something, sometimes because you didn't get to test that bit of code. But whenever a system turns live, after a while (Sometimes it happens pretty quick...) the system needs to handle something you haven't tested.
Sometimes even an unexpected failure. Sometimes network lagging causing timing issues.

Few of these times, you encounter what I would like to call a gremlin. That's this illusive bug which impacts your system, occurs enough times a day to be considered as a problem, but not enough so it's easy to reproduce.

The worst thing programmers love to do is mark it as 'irreproducible', throw it back at the QA, and do something else.

Advice for this stage: Don't. QA would probably not be able to reproduce it, and even if they would, it would be difficult for them to do it in a consistent manner so that you'll be able to gain from it. You need to help them. These things escalate fast, so don't put yourself in the position of the developer who tried to put the mess under the rug.

Start digging. And sometimes, the solution requires processing through endless logs (Or even add these logs). Sometimes a lot of code is involved. And after a few hours, if you still haven't found it, you find yourself repeating your actions, adding more logs, running sequences again. You've entered a stage of tunnel vision, where you can't look around.

Best advice for this stage: Stop. Go get coffee, go home, call someone, take a break. My best solutions came from getting some distance from the problem I've been working on, in order to clear my vision and be able to try a new approach. Another fresh set of eyes could work as well.

Happy hunting.

Who wants to be a hacker?

<rant>
One of the internet's greatest achievements and failures is the democratisation of skills.
The internet has lowered the barriers for everything:
Want to be a journalist? Open a blog.
Want to be a film maker? Get your cell out and upload your 15 second masterpiece to Instagram.
Want to be a programmer? Take an online course.

Want to be a hacker? No, it's too dangerous, now with the NSA and stuff. The original hacking was considered the cool and 'living on the edge' side of geekness, and can now put you in jail. But hacking has gone a serious downgrade, from pioneers and brilliant yet morally challenged techies, to just plain people inventing and integrating stuff.

So why is hacking all the rage now? Unfortunately, geek is out of fashion. It's not a strong enough word for the tech savvy. Ninja isn't anymore as well. So hack is the next 'sexy' term for what we use to call 'automation expert'.

Check out this headline: "The free tools that let you hack your whole life".
What is actually means is "tools to automate and integrate different facets of your physical and online life."
Don't get me wrong - I think that the fact that cheap hardware running linux and cheap controller boards help you implement great ideas and lower the barrier for innovators is great. I think that it's quite similar to the 3d print revolution. But this isn't hacking.

So it's all about marketing. If I see someone who calls himself a 'hacker' in his bio or profile, I would stay away - He might be a former 'ninja' or a 'wizard' or, god forbid, a self proclaimed 'geek'.
</rant>

Yours truly during a "hack" session

The real cost of user acquisition

Companies spend a lot of money on user acquisition.
From expensive ad campaigns, to shows and events, PR, community and more.
However, learning by a major technology company that is in dire need for cash in order to survive, looks like buying your user is not a scalable model.
If a users costs you 100$ to acquire, and then spends 10$ every month, but leaves you at the end of the year, your margins are too small to grow on.
That specific company has millions of paying users, but is bleeding money.
Perhaps real life human community management might be cheaper in the long run than 'buying' your users, or maybe you can try and get a different income than just your subscription service. If you have millions of users, that might just be possible.

Java, c# and the Object Oriented problem.

Oh, god.

I've recently gone over quite a few lines of code written in Java and C#, and found that most programmers have the tendency to over design their applications when using these languages.

A simple Java process that needs to read a file, process it and insert to a database had hundreds of redundant lines of code and objects, a lot of parameters, most of them never in use, and object hierarchy with no purpose whatsoever.
Another C# server was using a useless 5 layer model, most layers just transport data from one layer to another.

My conclusion is this: Either programmers want to demonstrate their knowledge of language abilities no matter the cause, or they're thinking too much about architecture and future possible features, and less about actual functionality.

Some tips that would save you some time and simplify your design:

- Read before writing your code. Almost every problem was already solved, and most of the solutions have already been published online. Stack Overflow already has great answers to ~90% of my questions. The rest I code myself.

- Configuration parameters that don't get changed should not remain in configuration. Some applications have two files - 'customer' configuration and 'application internal' configuration (Known only to tier 3 and up). Then consider moving the 'customer' configuration to a database.

- 20, 200, 2000, 20000: When coding enterprise applications (Big servers, probes, whatever), you should always imagine how much code customisation you need for 20 clients, 200, 2000 and then 20000, etc.: Pick the number you think you'll have in the next year. Your application should support the next level. (i.e. - If you think you'll support 20 customers this year, code as if you'll have 200 to support)

- If all your methods (Not members) are overridden, you should not use inheritance. Use a data member inside your objects instead.

- On the other hand, if all that differ between 10 objects is one function with 3 lines of code, one object with a switch or a decorator pattern might be more effective and easy to understand.

- If a layer in your application is just for communication between two layers, remove it.

- Java has lots of libraries. Do not use all of them. Try to find focused ones that fit your need, and not load the whole jboss stack just for a logger. Remember that class loaders eat up a lot of memory.

- Keep your eye on the target. Be lean. I would rather debug and fix a small amount of code which does its purpose than try to dig in a huge pile of code which does the same.

- Long functions are death. If a function contains more than 200 lines of code, split it to 4 functions.

- Throw your commented code to the trash. No one needs it. This is why they invented source control.

- Get a friend to code review you. Let him be the pilot during the review. If you find yourself explaining too much during the review, you've over designed your code...


And finally, something positive: In this post, one of my most popular, I wrote about the untapped computer power. Yesterday Slicify commented on the post: They've done EXACTLY that - And it looks very promising. Good luck guys!

An over designed Lego car wash

The essential startup toolkit

Not too long ago, software development was an expensive deal.

Development tools used to cost a lot of money, project management and documentation tools cost money, servers cost money, internal network, telephony, office space etc. etc.

Software development practices, on the other hand, aren't that different - Technology is, but the product cycle is largely the same - scrum and agile like methods exist for 20 years now, they were just called micro management :)

I remember coding in Borland C or early versions of Visual C++ (There was no visual studio back then, just a collection of MS tools), writing documentation in Word, updating my Project file, and using a shared network Novell drive. My computer was running windows 3.11, which was considered the standard OS. And none of that was free.

And that was only money. Setting up your business took time. Buying software (At a store...) gave you a lot of discs. Configuring a company network required a specialist. Installations took forever .(Remember disc 3 out of 14?)

Now all you need to have is a computer. It can run a free version of Linux. And if you don't compile, in could also be a cheap Chromebook. Hell, even if you DO compile, there are SAAS platforms which do that as well.

Servers? Basic SSD hosting would cost you ~60$ per year. Monthly internet access + Router + Cell phone would cost ~50-100$ Monthly. Need linux servers? Get a Pi for 25$. Need a phone to test? Use your own :). The only hardware that's relatively expensive would be if you want to develop iOS app, that would set you a minimum of 600$ for a mac mini and 230$ for an iPod touch... (Plus a 99$ yearly developer subscription...)

And all the rest is free. From task management to development tools to server software and source control, everything is completely free (To a certain scale, of course).

The only thing that's really expensive?
Your time.

Now go and make the most of it!

JVM... Don't call it a comeback!

After being away from compiled languages for a while, I've been consulting for a company which uses Java for development.

First time in a while (Forgoing my Android apps, which are too plain to call 'real' java programming), and I must admin I find going back to the code/ compile/ deploy/ test cycle quite tedious - Scripting languages have made me quite impatient :)

Setting up a development environment is hard. The specific startup had no 'real' development and deployment environment, and being an 'ant' fan I created my own setup (maven got me too confused), so I could work.

The advantages, though, are obvious - You make less spelling mistakes. You can use inheritance (Important for some solutions). And because it's a 'device mode' program (Rather than most of my recent work, which is GUI related and needs a touch...), you can actually automate unit tests!

And now for the question - Is there a need today for high level VM type compiled language? (Like C# or Java)? The same programming that I'm doing now could be done with php, or even node.js? (By writing a simple bridge between node and the c libraries...)

I'm actually not sure by now. It's possible that the next generation of programmers would never know what compilation means.

Thoughts about tips for entrepreneurs

Everyone is posting tips for startups, tips for entrepreneurs, tips for your business, tips for how to sell your company, tips for how to wake up in the morning.
Hosting meetups, conventions, non-conventions, garage meetings, beer meetings.
Talking and talking and talking.
Writing "The best advice I've got so far is" articles.
Posting and reposting.

I read a lot of these. Some of them are very nicely written, some of them are obvious and corny.
Seems like a lot of these people forget they were also a bit lucky to get where they are.

My thought - Reading is great, just don't forget to believe in yourself as well.
Don't try to be what you're not. If you're not the no. 1 type, don't force yourself to be the CEO.
If you're not the sales person, don't try to behave like one - Try to sell things the way YOU would, and convince people your way.
And if it doesn't work - Find someone for your team who can do that. In a well balanced team, members complete each other, not just complement themselves.

There's no such thing as a lucky strike.

A while ago, I was managing a large beta project for a large enterprise company. While preparing a thorough integration test plan, I've began to see my document page count rise and rise.
Consulting with my boss about the possibility to repeat this plan week after week with QA (As most of it was GUI, automation wasn't that possible back then), she told me a very smart thing:

- "If it wasn't tested, assume it's not working".

Simply put, whenever posting code to a production environment, even the slightest of changes, test it. See it with your own eyes.
Especially if we're talking about a startup environment, where everything should be as quick and there's no QA - Be extra careful. If you've posted your code without testing and it worked once, you're lucky.
But luck won't hold up forever, and your users will suffer.

Take a couple more minutes and a deep breath and test it.

Most cases, you'll be glad you did.

Performance - Where it counts.

A good report does magic with large data.
It is supposed to take millions of records, and summarise them into a visual entity that transforms into something meaningful for the user.

Recently, in one of my sessions, a client wanted me to focus on improving performance for a specific report in his system.
Report was taking 5 minutes to generate, clogged the system's database, and was comprised of one of the largest SQL statements I've seen in my life.
Instead of starting to spend hours and hours trying to optimise and dig deep, something that would cost my client a lot of money, I asked him a simple question:

- Who produces this report, and how often does it happen?

Turns out it was a weekly (Even monthly in some customers) report, printed and handed out to a manager.
Assigning a periodic process running on a backup database, and automatically sending the result via mail to the manager saved a lot of money and headache to my client.

Performance is important, but you should always focus on improving it where it makes a real difference.

Do it where it counts!

Ride the whale...

Reaching critical mass is crucial for every internet, service oriented or app based startup.
This is even harder when you're an anonymous, bootstrapped startup (Like us at InsideMy.co:)), without much budget for marketing but your precious time and some change for your servers.

So how DO you reach critical mass?

One way is to tediously knock on doors. Keep on the momentum, send more mails, gather clients one by one, and hopefully you'll have enough so the business starts 'driving' itself.

The other way would be cooperating with someone big that can carry you. If you can help their customers and convince their gain from you, as well as quantify it (How much traffic they will gain, money, more customers etc.), you might be in for a nice ride.
This also requires knocking on doors, and some careful management - Especially since if your idea is good, it might just get stolen.

The most important rule - Believe in yourself, and your product, but if you want to 'ride the whale', concentrate on what him and his customers gain.

That might save you a lot of door to door sales.

Whale

The new Macbook Air 11 - From a personal point of view

After spending two years with the Macbook Air 13 (2011 i5 edition), it was time to say goodbye, and get a new laptop.
Decision was made very easy with the 2013 Macbook Air Haswell upgrades - The only thing left to decide was whether to get the 11" or the 13", since in terms of performance they are completely identical.
I went with the 11", only because I wanted to experience something new - The difference in weight and form factor wasn't that big, and screen resolution is quite similar.

My usage is quite plain - Running an IDE (XCode, Eclipse or PHPStorm), a stack (Usually AMP or Node.js), and a browser or emulator, and sometimes Office.

My impressions so far - Wow.

Though performance doesn't feel much faster than the 2011 model (Which was plenty fast for my usage), the Air runs much cooler, and lasts between 7 to 10 (!) hours, depending on how wifi heavy I am.
For a machine that weighs almost like an iPad, this is quite amazing.

And when people ask me "Why don't you just get an iPad", I simply say - An iPad with 128GB SSD costs 800$. Add a 100$ keyboard to that, but you still can't run a stack.

Sorry, for me, this is the best laptop in the world.

At least until the next generation comes out ;-)

My new friend, working on InsideMy.co's stack

Momentum

A programmer's job is creating code.
This means that if you're a coder, you need to sit down and write code. Sometimes, a lot of code - But that's ok - Best coding sessions I've had were not only hard work, but a flow of creativity that you don't want to interrupt. (By the way - The same rules may apply for preparing a long document or a presentation)

When writing a new module (Or even server), the hardest thing, after the whole tedious buildup (Ideation and design processes, which could take months, especially if you've got other code to maintain), would be actually sitting down and writing the code!

I find that the tallest barrier is usually getting yourself to the position where you've got 'something to see'.

This means that setting up the environment, deployment, build and server settings should be taken care of, so you can finally sit down and get into the groove - Do it as fast as you can.

Once in there, I find the skeleton coding approach the most effective to get the momentum I need, especially since it's the fastest way I can see the program come to live. In general, once you've got one flow nailed down, the others follow quite easily.

So get your headphones on, turn your phone off, and get coding!

Performance issues? Remain calm and analyse.

Web companies are all about growth.
But also about speed.
It's all about getting your great idea out there, as fast as you can, which means scale and performance issues could be left 'for later' (Which is mostly a good idea at the beginning stage, when resources are sparse, and time is an issue).
Once your service scales from 100 users to 10000, you will encounter performance issues. If you have an app, response times would slow to a halt. A site, data loads slow.
In 2013 Google IO UI sessions, it was mentioned that app users tend to close their app when waiting for more than 10 seconds. While that might sound harsh, imagine tapping, waiting 10 seconds, then tapping again, waiting again - I would uninstall such an app, or never visit such a website (Unless they have something I really, really need, in that case I'll look for a competing product before uninstalling)

Clear your head. Analyse the situation.

So, what do you do?
First, don't pannick. Performance issues happen to everyone. (Kidding)
But be focused, because time is of the essence here.

An 'automatic' go to solution is upgrading your hardware - I wouldn't go there unless I was really desperate - This is hardly ever a scalable solution.

First thing you would want to do is analysis.
The base for all solutions shouldn't be by intuition alone - This could lead you to waste time on ideas that may or may not bring the solution, and waste valuable time.

- Analyse each step by time, dump it to a log file. Find the 10 most time consuming tasks, and select the easiest ones to take care of.
- Analyse DB calls - See which ones are being performed to most, or which ones take a lot of time.
- Analyse insertion rates - Maybe a queuing mechanism could solve some bottlenecks.

- Always use a perl script to 'clean' logs, do count operations on logs, and a spreadsheet to calculate and sort stuff - These are the best ways to get insights.
- Call a friend. Four eyes are always better than two.
- Call an expert. It's cheaper to pay someone for two expensive days of work and get your issues solved than lose a week of momentum.

And a final note - Don't try to rewrite your server in two days of 'no sleep'... ;)

Good luck.

The short blanket

One small rule - If you don't know all the execution paths of a code and are about to make changes, beware.

Especially if your software is made of a lot of modules speaking with each other, it's difficult to know what impact one bug fix could have over interacting modules.

If you don't have an automated test suit that covers all your execution paths, my best suggestion would be a simple file search on the method changed - This would at least give you a hint of what to check in order to make sure you'r covered.

Otherwise, this might happen:

New beginnings!

I am recently making slight changes in my professional direction.
As more and more freelance consulting opportunities rose, I've decided to make the move, and become a consultant, as well as work on my new pet project.

Along with a friend, we're creating a website focusing on bringing great stories from the startup nation. After a month of test run, more than 50 startups joined our community, ranging from Eyecam, servicing growing video devices (Like Google Glass), via BestMatch (Online shopping) to DaPulse and even Kaltura.

If you're interested in getting the latest news from the startup nation, visit us, or join us in Facebook!

Have a great weekend.

Reading time #5!

Here we go again - The fifth instalment in the 'good reads'!

- "The software is processed by more than just the computer. It's also processed by a human sitting in front of the screen". Take the time to watch this: A Great lecture from Google IO about cognitive science and design.

- Having a great product might not just be enough. Check out this article "So you think you can go viral?", In order to find out the challenges behind the assumptions about viral products.

- With Flickr been rebuilt to a whopping 1TB of free image storage, Tumblr bought, and Hulu on sight, Yahoo's new strategy is marking the comeback of the all-mighty mega portals, spending billions of dollars basically on user acquisition. Yahoo aims high. We'll see how that evolves...

And, finally, check out my new pet project: The startup nation feed, bringing you great stories from the startup nation!



Previous reads:
#4

#3

#2

#1

Ah, the funnel

Ah, the wonderful funnel.
The science of users acquisition, retention, and conversion... The web has moved from pageviews, to clicks, to conversions.
And so should you!

Got your product up? Want millions of users to register and use it? Want to convert non paying users to paying users?
Some fun funnel basics.
- If your users register for free, make the initial registration almost transparent. email, that's it. (At least until you got enough viral buzz). Maybe not even by logging in and allowing an app to 'post to your facebook profile'. We just met.
- Be nice with mails. Linkedin has the habit of 'bombing' you. Twitter bombs you once you neglect them. Actually, everyone bombs you unless you learn the tedious process of disabling or throttling mail traffic. However, you're not LinkedIn, and every user pressing 'unsubscribe' would be lost.
- Try to personalize the mail message. Even if it's automated, a personal call for action is much better than a generic one.
- Always mention what value you give to your users. Real value, no slogans, especially for paying ones. You can also do that by giving value statistics to your user (250 people have looked at your profile...)
- Use analytics. If your registration has more than one step, see how many 'leaks' you've got, and improve. Try to find out which people opened a form, but never filled it. Those might need an extra push. You can automate that one as well.
- Remember what differentiates you from the competition, or from similar services. Remind that to your audience as well.

Happy hunting!

p.s. - If you're a startup, register here, and get featured!

Things I've learned from freelance projects

Few of my side projects in the last two years have been managed without an office.
As most of them were small, web based projects, management overhead was more than simple.

Other than the initial 'sale' meeting, all communication with the client was via mail, phone or even web tools. One project didn't even have a face to face meeting with the customer, just phone, contract via mail, and follow up calls and mails - And that project even needed a backend integration with a medical database!

Things I've learned from such projects:

- Listen, listen, listen. When communication is limited, you need to make SURE you 100% understand what the customer needs. Repeat it in your own words, make sure they agree and know EXACTLY what to expect from you.

- Contract signing. Make sure you are covered. Make sure that scope is 100% agreed upon, and changes cost more money. Payment milestones are REALLY important these days. Make sure that after an agreed certain 'live' period, project goes into maintenance mode - You don't want that phone call after 6 months, when you're already knee deep on something else. A contract is also the best way to see the way your project is going to shape, for better or worse.

- Sandbox communications. The best way to show a project underway is letting your customer see the work in progress. Set up a place where you can share your ideas with your customer, make milestone demos and receive feedback. Make sure it doesn't cause too much overhead - If the customer likes to make lots of 'pebble size' comments and corrections, space out your demos, so you can handle them in bulks, rather than in an annoying, fluid, ongoing dialog.

- If you can, get help with QA. Your friends, your wife, whoever can help. Sometimes you miss out on obvious things, even typos.

- It's a known cliche, that your best reference are your successful projects, however, if you see that a project is headed to a clash with the customer, remember that word gets around - Try to resolve issues, even if it means biting your tongue, and losing some money. Remember that the best protection you have is your contract...

Good luck!

The two syllable rule.

Just a thought:

What do google, facebook, linkedin, twitter, tumblr, mailbox, dropbox, flickr, yahoo, wordpress, youtube, blogspot, eBay and many other internet giant have in common?

Two syllable names.

Easy to transform into a verb (Google me), easy to remember, catchy.

34 out of the 50 most popular sites in Alexa's index have two syllable name.

If you're aiming high, this should be part of your naming strategy.

Of course, there are recent exceptions, like pinterest. But those are exceptions.

We've built a great product. Now what?

Previously, I had a post about Google Plus, the great party everyone showed up to, and a minute later went home.
After talking to some entrepreneurs recently, It seems like getting the crowd to take a look at your product is one challenge, and then getting them engaged over a period of time is even more challenging.
So after identifying what the world needs, and how to give the world exactly what it needs, got some feedback from friends, all that's left is bringing people in.
A few tips on doing that without spending on ads and promotion:

(I'll use a flower shop analogy).

- Try to think of one great benefit your potential user (Customer) receives from your product. Formulate that into a strong message. ("We promote flower shops" -> "The best way to promote your flower shop").
- Look for where your potential user hangs out (Online flower shop owners online forum). Stalk it, see how you can begin promoting yourself there.
- Even better - Find out your 'dealer' there (A power user...). Do what you can to lure him: Promise him to be featured for free. Make him get the customers to you.
- Now find 10 of these...

Marketing used to be based on ads, impressions, clicks.
Reliable, engaging marketing is based on opinion makers.

Or, you can do like these guys.

A small rant about Apple

If you have an app or a book published for both Google Play store and the Apple iTunes store, you must know that one as well:
The second you login into the Google Developer console, you see a neat little dashboard, presenting your apps statistics.
With the iTunes connect portal, you need to press two annoying links before you need to wait a couple of seconds and then, hopefully, you get your daily download graph and stats for your app.

This is annoying.

It's amazing how Apple, which stand for design for most people, offer such poor usability for its developers. And don't get me started about XCode.

The X of Y

People which have a hard time defining what their start up does, find it easy to use another start up as a metaphor for what they do:

- "The Groupon of vacations"
- "Like Twitter, but with Video"
- "Like Tumblr, but cooler"

This is something you wouldn't do on your website, right? So why would you introduce yourself like that in person?

Try to come up with what that company does (Go to the "about" in that company's site), and replace that with the company name:

- "Daily deal on the best vacations" (Vacations Groupon)
- "A social video information stream" (Video Twitter)
- "The coolest way to share everything" (Cooler Tumblr)

Still simple, much better.

Moonshooting.

Well, looks like there's a new buzzword in town: The moonshot.

The basic term means that instead of thinking how to solve a problem incrementally (Improve by 10%), you try to think how to solve it 'exponentially' (Improve 10 times instead).

Though there are already 'exponential thinking' courses taken at universities, Wired had a special issue about 'thinking big', and a nice website with all sorts of neat videos from top scientists and CEOs about how the world's problems are going to be solved in the coming years.

The way I see it, in today's world, this type of thinking is essential in today's scale factors. If you work in the b2c business, and solve a problem with data, you already need to think by millions and millions of transactions - That's exactly the 'big data' thinking.

So the next time you think about a redesigning your system for performance, try to think how it would handle 10 times more users. or 1000. or 1000000. The world has gotten big, it's time to scale our thinking as well :)

School yourself!

The tech world is all about tech fashion. Buzzwords come and go, new OSs, frameworks and stacks come and go, but sometimes, instead of learning the 'framework of the moment', you would want to learn some completely new fields and skills.

Luckily, this is really easy to do these days.

Udacity, founded by the head of Google X (Google's futuristic project lab), offers plenty of courses, all of them free. From web development to parallel computing, it's all there, neatly packed, with tests, certificates and all.

General Assembly offers video courses, some free and some paid, and focus more on design and entrepreneurship.

10gen, creators of MongoDB, have 3 great courses on database, from programming to scaling and maintenance (Of course by using mongo...)

There are plenty of other resources online - Just pick what you want to learn, and go there.

Spending 2 hours a week expanding your horizons and skills - It's worth it, even if just for the fun and challenge.

Is 7" the new 10"?

7" devices are a rage.
After the success of the first 'wave' of 7" devices (1st Gen. Kindle Fire, Nexus 7), and the iPad Mini cannibalizing both iPad AND iPod sales for Apple, the 7" (to 8") tablet category seems to be taking over the tablet market.

After playing with 7" devices for a while (Both nexus and iPad mini), I can definitely understand why. The form factor is simply more successful than 10" tablets. Easy to hold with one hand (iPad Mini feels as light as a kindle), good enough to work with (Thumb type is possible) - Seems like this is the spot for tablets.

So, while 10" tablets are getting more and more laptop-like (Windows 8 convertibles, for example), 7" devices will get retina-quality screens, and probably become the new form factor size for tablets.

The untapped computing power

Now that cloud computing has taken over the web, it's time to think what would be the next step. Considering that the cloud providers are making money out of renting CPUs and storage. But there's already a lot of CPU power and storage connected to the web, and not being used most of the day.

This thought kind of takes me back to a '97 project called seti@home. That project used home PCs to parallel process radio signals from space. And though users didn't gain much from this project except for a thank you mail, times have changed since.

My wife, who has a day job, has a PC connected to the internet, operating all of the day. Imagine you can rent your computer for processing power or storage. Such network infrastructure already exists, and it would be pretty simple to install a client which receives jobs or lends storage for a cloud based network. As most search/ image processing/ big data analysis engines use map reduce and distributed storage nodes, such a network could provide a reliable, viable alternative to current cloud providers.

Been doing a lot of thinking about this lately. Who wants to join me and implement such a network?