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!
Saturday, November 16, 2013
Monday, October 21, 2013
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.
Monday, October 14, 2013
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>
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 |
Thursday, October 3, 2013
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.
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.
Monday, September 23, 2013
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!
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 |
Wednesday, September 18, 2013
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!
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!
Tuesday, September 10, 2013
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.
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.
Subscribe to:
Posts (Atom)