oonaxzieoo’s Weblog

i agree with what i’ve read that says if you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource. if developers will think first of their users then definitely if the users think that they’re being prioritize by the developers in return they’ll be the most valuable resource of the developers.

this chapter overviews the history of hacking. the history of how or when did hacking starts was mentioned in this chapter. for me this chapter is boring. the content is very technical. they mentioned things that i wasn’t familiar. it gave me a hard time to finish reading the whole content because of the technical terms. all i know is the content is all about hackers andi how when and why there is hacking .

honestly it gave me a hard time understanding the whole content. this chapter talked about hackers and their culture. also, in this chapter open-source was mentioned. base on what i’ve read i think this part will talk about hackers and their culture. we get to understand more about hackers. i also think that after you read the introduction you get to understand more the concept of a hacker.

Finals

iNettuts

Yahoo! Pipes

WordPress

this chapter mentioned about how we should not make it a very long sign up process because people might end up not finishing it. There should also be a free trial or demo without purchasing the application. Your free trials should be available for everyone and anytime so that customers will really be attracted. You should ask the things that are very important so that it would be short. The customers may cancel or leave their account without any penalty. You should avoid long term contracts and sign up fees you should ask for fee if they are already using it but you need to ask for payment monthly and you should avoid long term contracts because people avoids it because sometimes they ran out of money or they are not interested with your application. But it is better if there are no contracts needed to sign in. if there are some increase in the price or etc you should make your notice earlier so that they can prepare the payment early and you should explain to them properly.

this chapter overviews about how to think of your product as a person. What type of person do you want it to be? Polite? Stern? Forgiving? Strict? Funny? Deadpan? Serious? Loose?. this chapter mentioned also that, Once you decide, always keep those personality traits in mind as the product is built. Use them to guide the copywriting, the interface, and the feature set. Whenever you make a change, ask yourself if that change fits your app’s personality.

this chapter also mentioned aboout:

Don’t write a functional specifications document

These blueprint docs usually wind up having almost nothing to do with the finished product. Here’s why:

Functional specs are fantasies

They don’t reflect reality. An app is not real until builders are building it, designers are designing it, and people are using it. Functional specs are just words on paper.

Functional specs are about appeasement

They’re about making everyone feel involved and happy which, while warm and fuzzy, isn’t all that helpful. They’re never about making tough choices and exposing costs, things that need to happen to build a great app.

Functional specs only lead to an illusion of agreement

A bunch of people agreeing on paragraphs of text isn’t a true agreement. Everyone may be reading the same thing but they’re thinking something different. This inevitably comes out later on: “Wait, that’s not what I had in mind.” “Huh? That’s not how we described it.” “Yes it was and we all agreed on it — you even signed off on it.” You know the drill.

Functional specs force you to make the most important decisions when you have the least information

You know the least about something when you begin to build it. The more you build it, the more you use it, the more you know it. That’s when you should be making decisions — when you have more information, not less.

Functional specs lead to feature overload

There’s no pushback during spec phase. There’s no cost to writing something down and adding another bullet point. You can please someone who’s a pain by adding their pet feature. And then you wind up designing to those bullet points, not to humans. And that’s how you wind up with an overloaded site that’s got 30 tabs across the top of the screen.

Functional specs don’t let you evolve, change,and reassess

A feature is signed off and agreed on. Even if you realize during development that it’s a bad idea, you’re stuck with it. Specs don’t deal with the reality that once you start building something, everything changes.

So what should you do in place of a spec? Go with a briefer alternative that moves you toward something real. Write a one page story about what the app needs to do. Use plain language and make it quick. If it takes more than a page to explain it, then it’s too complex. This process shouldn’t take more than one day.

Then begin building the interface — the interface will be the alternative to the functional spec. Draw some quick and simple paper sketches. Then start coding it into html. Unlike paragraphs of text that are open to alternate interpretations, interface designs are common ground that everyone can agree on.

Confusion disappears when everyone starts using the same screens. Build an interface everyone can start looking at, using, clicking through, and “feeling” before you start worrying about back-end code. Get yourself in front of the customer experience as much as possible.

Forget about locked-in specs. They force you to make big, key decisions too early in the process. Bypass the spec phase and you’ll keep change cheap and stay flexible.

Useless Specs

A “spec” is close to useless. I have never seen a spec that was both big enough to be useful and accurate.

And I have seen lots of total crap work that was based on specs. It’s the single worst way to write software, because it by definition means that the software was written to match theory, not reality.

—Linus Torvalds, creator of Linux (from: Linux: Linus On Specifications)

Fight the blockers

I found the people insisting on extensive requirements documents before starting any design were really ‘blockers’ just trying to slow the process down (and usually people with nothing to contribute on design or innovative thinking).

All our best work was done with a few concepts in our heads about improving a site, doing a quick prototype (static), changing the design a bit and then building a live prototype with real data. After kicking the tires on this prototype, we usually had a real project in motion and good result.

zen garden : http://oonaxzieoo.site50.net/

fancybox: http://oonaxzieoo.site50.net/fancybox/fancybox.html

lightview: http://oonaxzieoo.site50.net/lightview/lightview.html

generator: http://oonaxzieoo.site50.net/ajax/generator/

getajax: http://oonaxzieoo.site50.net/ajaxgetrequest/IO.html

jquery: http://oonaxzieoo.site50.net/jquery8

cart: http://oonaxzieoo.site50.net/cart/cart.php

Keep your code as simple as possible
You’d think that twice as much code would make your software only twice as complex. But actually, each time you increase the amount of code, your software grows exponentially more complicated. Each minor addition, each change, each interdependency, and each preference has a cascading effect. Keep adding code recklessly and, before you know it, you’ll have created the dreaded Big Ball of Mud.

i think i agree with what the author said about keeping your codes simple. the length or number of lines do not reflect how effective and efficient your codes are but i think that the longer your codes are the more complicated it gets.

i also agree on what the authors said about choosing tools that keep your team excited and motivated because if the programmer are happy with what they’re doing they will be motivated to accomplish their tasks and they’ll be productive. i agree with what they said that happiness has a cascading effect. Happy programmers do the right thing. They write simple, readable code. They take clean, expressive, readable, elegant approaches. They have fun.

In this chapter, it was stated that you should design the interface first before programming. Too many apps start with a program-first mentality. That’s a bad idea. Programming is the heaviest component of building an app, meaning it’s the most expensive and hardest to change. Instead, start by designing first. html designs are still relatively simple to modify (or throw out). That’s not true of programming. Designing first keeps you flexible. Programming first fences you in and sets you up for additional costs. also, it was mentioned in this chapter that the other reason to design first is that the interface is your product. What people see is what you’re selling. If you just slap an interface on at the end, the gaps will show. We start with the interface so we can see how the app looks and feels from the beginning. It’s constantly being revised throughout the process. Does it make sense? Is it easy to use? Does it solve the problem at hand? These are questions you can only truly answer when you’re dealing with real screens. Designing first keeps you flexible and gets you to those answers sooner in the process rather than later. i definitely with what the authors said that the interface must be done first. coz that is the first thing that will attract your market.. so i think you should take time first in thinking how and what to place in ur interface.

it is said in this chapter that, before hiring we should work with prospective employees on a test-basis first. before we hire anyone we give them a small project to chew on first. We see how they handle the project, how they communicate, how they work, etc. Working with someone as they design or code a few screens will give you a ton of insight. You’ll learn pretty quickly whether or not the right vibe is there. i agree also at the part when the authors said that we shouldn’t believe or depend on what is written on their résumés. also, i agree with what they said that Open source is a gift to those who need to hire technical people. With open source, you can track someone’s work and contributions (good or bad) over a lengthy period of time. by that, we can judge them by their actions not through words.

That means you can judge people by their actions instead of just their words. You can make a decision based on the things that really matter:

• Quality of work
  Many programmers can talk the talk but trip when it comes time to walk the walk. With open source, you get the nitty gritty specifics of a person’s programming skills and practices.
• Cultural perspective
  Programing is all about decisions. Lots and lots of them. Decisions are guided by your cultural vantage point, values, and ideals. Look at the specific decisions made by a candidate in coding, testing, and community arguments to see whether you’ve got a cultural match. If there’s no fit here, each decision will be a struggle.
• Level of passion
  By definition, involvement in open source requires at least some passion. Otherwise why would this person spend free time sitting in front of a screen? The amount of open source involvement often shows how much a candidate truly cares about programming.
• Completion percentage
  All the smarts, proper cultural leanings, and passion don’t amount to valuable software if a person can’t get stuff done. Unfortunately, lots of programmers can’t. So look for that zeal to ship. Hire someone who needs to get it out the door and is willing to make the pragmatic trade-offs this may require.
• Social match
  Working with someone over a long period of time, during both stress/relaxation and highs/lows, will show you their real personality. If someone’s lacking in manners or social skills, filter them out.

When it comes to programmers, we only hire people we know through open source. We think doing anything else is irresponsible. We hired Jamis because we followed his releases and participation in the Ruby community. He excelled in all the areas mentioned above. It wasn’t necessary to rely on secondary factors since we could judge him based on what really matters: the quality of his work.

I also agree at the part where they said that we should get well rounded individuals. it is good to have well rounded individuals at least it wouldn’t be diffuclt for us to teach them the basics. and it is also possible that once in a while they’ll be tasked to do different jobs. everyone should be willing and be able to cope up with changes in their tasks.

you should also hire people with enthusiasm rather than know-it-all people. also, you should hire someone you can trust to get things done when left alone. Someone who’s suffered at a bigger, slower company and longs for a new environment. Someone who’s excited to build what you’re building. Someone who hates the same things you hate. Someone who’s thrilled to climb aboard your train.

it is also suggested in this chapter that if we’re trying to decide between a few people we should always hire the best writter because being a good writer is about more than words. Good writers know how to communicate. They make things easy to understand. They can put themselves in someone else’s shoes. They know what to omit. They think clearly. And those are the qualities you need.