We all have a lot to learn.
My first programming job was a 'lone' programmer in a group of testers, writing telephony test simulators.
The activity was successful, and after two years I found myself with two workers, making wonderful stuff happen, and changing the way my company works.
After trying, unsuccessfully, to be a beta program manager (Too early for a 25 year old kid...), I was given another programming job, this time under a guru.
The first two months were looking quite good. Re-brushed my c++ skills, got my confidence back, made some stuff happen.
Then came the evaluation talk.
And I got my ass handed over to me.
Seems that I wasn't quite that good, according to my boss. Messy, hard to control, over confident, lots of bugs etc.
I was quite angry after that conversation. Felt like kicking his ass. Luckily for me, I had the whole weekend to relax. And then I understood something. This was actually my first job programming. In the phase before that, I had no one to tutor me. I got great results, but I was the one setting the expectations, as there were none...
So instead of explaining how wonderful I actually am to my boss (Who obviously thinks a bit different), I need to give up my ego, and start learning from him. He was not the one they would fire if I'm not up to par with his expectations...
So I've asked him to accompany me in my next mission, step by step, and make sure I will not fail.
Break down my mission, set expectations and success criteria for each mission.
I know how to write code. I just need to align myself to his methods. And who knows, I might even learn something.
In that particular case, I've learned a whole lot. Both professionally and personally.
The past year I had to give up on a good programmer which chose the other way. After he got handed over to another group, he decided to quit, in the middle of a version.
There are many types of programmers. But the ones team leaders like the most, and are most likely to promote, are the effective ones: The ones who can make the biggest impact, not necessarily the most efficient ones, the hard working, or the more thorough ones. These are great qualities, but they are not enough.
I will elaborate more on how to be an effective programmer from both the manager and programmer perspective, in my next posts.
y.
Tuesday, August 30, 2011
Sunday, August 21, 2011
Tip: The JSP surgery
So, you've invested a whole lotta love and money in your java based web server.
And it's fine. Really.
But now it's time for an overhaul. The UI is dated, and you want to bring some fireworks back.
The problem - Your team has changed, it's been a while, and all your team has done so far were some bug fixes and some features. And the web layer is written in good ol' jsp - No one really knows how to rewrite it. Recently I've encountered a similar project - All the team left, the design was terrible, but I couldn't make changes to the back-end, only the jsp files.
What do you do?
My suggestion is to divide and conquer!
Here's a quick recipe on how to transform your server script code into a web service.
First off, see which data you need the server to really generate. Usually, it would be user details, a data table, plus some attributes.
After that, have your jsp code generate JSONs instead of html or javascript code.
This shouldn't be that hard.
Analyze all your code, and prepare new jsp files for each type of data needed. Use the current jsp function calls - There's no need to rewrite the java layer: All these files should do is write a JSON response. You can use Arrays.toString(), or a JSONArray, or you can generate the JSON explicitly from object attributes.
Then you can begin writing your client from scratch, and use these jsp as a web service. You may later write some Java servlets to replace them, or (Better off) use jax-rs to completely get rid of the jsp.
Step by step, you'll see your web application transform into something a lot more comfortable to use and maintain. A real web service, without rewriting your back-end. And when you do get the time to update your server, you'll be able to do it with only minor client modifications.
Have a good development week, and stay tuned for more!
y.
And it's fine. Really.
But now it's time for an overhaul. The UI is dated, and you want to bring some fireworks back.
The problem - Your team has changed, it's been a while, and all your team has done so far were some bug fixes and some features. And the web layer is written in good ol' jsp - No one really knows how to rewrite it. Recently I've encountered a similar project - All the team left, the design was terrible, but I couldn't make changes to the back-end, only the jsp files.
What do you do?
My suggestion is to divide and conquer!
Here's a quick recipe on how to transform your server script code into a web service.
First off, see which data you need the server to really generate. Usually, it would be user details, a data table, plus some attributes.
After that, have your jsp code generate JSONs instead of html or javascript code.
This shouldn't be that hard.
Analyze all your code, and prepare new jsp files for each type of data needed. Use the current jsp function calls - There's no need to rewrite the java layer: All these files should do is write a JSON response. You can use Arrays.toString(), or a JSONArray, or you can generate the JSON explicitly from object attributes.
Then you can begin writing your client from scratch, and use these jsp as a web service. You may later write some Java servlets to replace them, or (Better off) use jax-rs to completely get rid of the jsp.
Step by step, you'll see your web application transform into something a lot more comfortable to use and maintain. A real web service, without rewriting your back-end. And when you do get the time to update your server, you'll be able to do it with only minor client modifications.
Have a good development week, and stay tuned for more!
y.
Sunday, August 14, 2011
Three nice tips for web developers.
Actually, two basic dev tips and one neat resource site.
First tip is regarding dynamic HTML. We've been encountering some rendering performance problems with huge tables, and after some investigation, here are some pointers:
Final tip is this site. Microsoft is putting a lot of effort these days - It's great to see them as the underdog. You'll find Azure php sdk, nice html5 references, and lots of useful resources. Check it out. I'm considering Azure for a project I'm working on, the php sdk seems quite cool.
Have a great week!
y.
First tip is regarding dynamic HTML. We've been encountering some rendering performance problems with huge tables, and after some investigation, here are some pointers:
- Do not use tables. They're bad for you, especially large ones, and nested tables. By the way, YUI creates lots of inner tables. You can read some more with this link, top answer has some great detailed arguments for you. I know it's a corny advice, but there are lots of frameworks out there that use tables, even gwt.
- Do not create each dom element separately - If you need to create a very large table/ chunk of html, it's better to create a huge html string and then insert it into dom for processing, rather than use the dom to create each element, and the append them. Think of it as using 1000 'native' calls from a VM rather than 1 long call. The overhead for each dom element is huge.
- Establish a maximum size for a list and browse through results. Google does that with search results, why don't you? You can cache results in javascript, or keep an index to the query and go back to the server to fetch the next n entries, but displaying one thousand items for a user is highly ineffective.
Second tip is rather basic - Regarding server/ client processing and separation. As we're moving towards cpu consumption related billing rather than permanent hosting, we need to rethink what we do on the server and on the client side. The main principal would be having the server perform validation and data (model), and do the rest in the client:
- Your server code should not create html. It should either create status/ session/ json, but not html. This is just a waste of server cpu. It speeds up server response, and when written well, makes client experience better. It scales a whole lot better.
- You must think of your client and server modules as replaceable. This means that if you're writing a server, imagine that you need to write two completely different (Say html and iOS) clients for it.
- If you're afraid that competitors may reverse engineer your client html/ js/ css code, you can always minimize it, or get an obfuscator.
Have a great week!
y.
Tuesday, August 9, 2011
Some updates...
Here's another one:
http://www.pninas.com/
Design was pretty straight forward, One page is all I needed (index.html + index.js).
I think I'm improving... This one was quite easy and fun to do.
In other notes, the simple blog is shaping up. In the beginning, I thought about how to differentiate the system from, say, um, Blogger... And decided on focusing on these features:
There's another project shaping up, but I'm trying to think if it has commercial potential...
Stay tuned.
http://www.pninas.com/
Design was pretty straight forward, One page is all I needed (index.html + index.js).
I think I'm improving... This one was quite easy and fun to do.
In other notes, the simple blog is shaping up. In the beginning, I thought about how to differentiate the system from, say, um, Blogger... And decided on focusing on these features:
- No Rich Text Editing. (So we'll be iPad compatible that way)
- One file attachment per post. User can then decide what it's going to be.
- Sample (Reference) viewer should be nicely designed, and with a separate (Maybe inline?) CSS.
- This time, try github for hosting. Just for fun.
In the meantime, Simple Gallery Management has gone through one more phase of update - Adding an attachment option for news post. You can get it here.
Tagging is there, but I haven't written the link between tags and items... Just being a bit lazy, I guess :)
There's another project shaping up, but I'm trying to think if it has commercial potential...
Stay tuned.
Wednesday, August 3, 2011
Start up Psychology: Of NDAs and meetings.
"But first, we need to sign this NDA agreement..."
You've seen the social network, right?
If you're meeting a lot with entrepreneurs, you might hear this a lot.
Every one wants to protect their most valued asset - Their wonderful idea that might change the world. And because most of them only get one shot at this, the one thing they fear the most is that some talented bastard would steal their idea, and get to the market before them.
So you're meeting with the ambitious young man/ woman/ team, and before they tell you how they might change the world, they pull up an NDA document, with thousands of words, all making sure you won't be stealing their precious idea EVER.
I've got a few small tips, that might help with that matter:
You've seen the social network, right?
If you're meeting a lot with entrepreneurs, you might hear this a lot.
Every one wants to protect their most valued asset - Their wonderful idea that might change the world. And because most of them only get one shot at this, the one thing they fear the most is that some talented bastard would steal their idea, and get to the market before them.
So you're meeting with the ambitious young man/ woman/ team, and before they tell you how they might change the world, they pull up an NDA document, with thousands of words, all making sure you won't be stealing their precious idea EVER.
I've got a few small tips, that might help with that matter:
- An NDA document might buy you peace of mind, BUT it won't really do the trick if someone really wants to steal your idea. Especially if it works. Big companies have big lawyers, small entrepreneurs usually don't. You can explain that to your partner.
- Try to get that document before the meeting. It's hard reading every paragraph when you're in a coffee shop. You won't be able to assess the risks.
- Ask for a time limit on that document. Three years is enough. You'll never know when you'll end up, or you might implement a similar idea in the future.
- Declare a possible conflict of interests before hearing the idea. Tell the founder that you might stop the presentation in the middle - If you've heard a similar idea before, or consulting to a company with a similar idea (Even technologically), you can stop the meeting (Just don't do that AFTER you hear everything), and invalidate the NDA. Protect yourself in that matter.
And, most important - Go with your instinct. If you don't feel comfortable with the NDA, or with your potential partner, you can stop the meeting any time, and depart politely.
It's more important to have fun and to work on something you believe in.
Tuesday, August 2, 2011
Adobe is going html5... Update on flex/html showdown
Subscribe to:
Posts (Atom)