is-ebiz o0a

site90 November 20, 2008

Filed under: is ebiz — hikaru011 @ 1:57 pm
Tags: ,

hi guys. please visit these sites:





Chapter 16 November 5, 2008

Filed under: Getting Real — hikaru011 @ 1:03 pm
Tags: ,


Chapter 16 is the conclusion chapter of getting real. Basically, this part summarizes all the chapters of the reading. It recalls on how to start your app, how to handle the people, how to multi task, etc. The first chapter tells that getting real starts on how to create a software backwards. Meaning creating first what will the end user will see or experience rather than starting with what the user will not be able to appreciate. The book also tackles on how to handle your people. Every people in the team should be working. Working in a way that a programmer should not always spend his time in front of the computer screen but he should also have knowledge on how to talk to clients. Every one on the team must multi task. It is also said in the book that a small company and small software has an advantage over big company and big software. There are a lot of insights we can get from this book. After reading and understanding all of the terms and insights in this book, you can now start your engines and build your own software.


Chapter 15 October 30, 2008

Filed under: Getting Real — hikaru011 @ 5:13 am
Tags: ,

To summarize it all up, this chapter talks about a few more steps before launching your
application. The first and second link talks about pre-launching the application. Getting Real
tells us readers that we should have a One-Month TuneUp before launching your application. You
have to test your application in order to tell whether the application is up and running.
With this kind of pre-launch, at least you still have time to may minor changes before the grand launch

The second link talks about not making “beta” an excuse. This link focuses on the word
imperfection. Getting Real tells us that we shouldn’t be wasting our time perfecting our application,
because it will never happen. There are no such thing as a perfect application. We cannot satisfy
every people. Some may think that this looks good with your application, others may say that it doesn’t.
Perfect Applications is a fantasy.

As I said in awhile ago, you cannot please everyone. There will come a time wherein
bad comments will arrive. You just have to “ride the storm”. Do not let them get to you. Do not ever
let them bring you down but use them as a motivation to keep you going. To help you make a better

The next link talks about knowing who your competitors are. You have to know them too so that,
you too may get some tips which will help you with your application. I am not saying that you will
get his/her idea. I am just saying that you may learn from your competitors. To learn from them,
Getting Real suggests that you, as an application maker, should indulge yourself with other applications
which may help you track your competitors.

Lastly, keep an open mind!:) With this kind of mindset, you are not just focusing yourself to this kind
of system. At least, when new trends show up, you are aware of it.


Chapter 14 October 29, 2008

Filed under: Getting Real — hikaru011 @ 10:25 am
Tags: ,

This chapter basically tells us on what way we should build our product and how to control it after release. In the first part, feel the pain, it says there that when building something, you as a member of the team, should be aware on what is really happening around. When you are a programmer, it is also necessary that you have knowledge about the design of the product, who is your customers, what is the scope of your product, etc. As a programmer, your job does not end on coding alone. You should also know how to deal with the clients and other stuff that your group does. In dealing with your customers, you should be polite. Releasing the product is not the end of your project life cycle. You also need to support the users or your clients. You should guide them properly on the basics like how to use or run the system. Manuals are often comes hand in hand with any product that we purchase. It is where we can read on how to use what we bought. In this chapter, it is said that try building a zero manual product. It means that build a product that is so simple and user friendly so that customer can easily get used to it. But I think when you build a product that has no manual; you should open your lines for customers’ tons of questions. You don’t need to please them just be honest and just answer up straight. For example, you experiencing some technical problems, you should inform your customers right ahead before they start to panic and believe me it will cause your company a lot of troubles and worries. But when you think that it is more work loaded when you set up a huge technical support center, you can just open up a forum online. There a customer can post his own reaction over the product and can also advise other customer.


Chapter 13 October 19, 2008

Filed under: Getting Real — hikaru011 @ 10:14 am
Tags: ,

Basically, this chapter tells us application builders, to formally and beautifully, tell
the people about your application. In order to do so, Getting Real suggests that we should
go from a teaser, to a preview then launch. Hollywood style! With this kind of style, it
will attract people at the same time, you will know if your application clicked or not. At
least, you haven’t actually released your application yet. Instead of releasing it without
knowing if it will click or not. Like what Getting Real said: “If an app launches in a forest
and there’s no one there to use it, does it make a noise? The point here is that if you
launch your app without any pre-hype, people aren’t going to know about it.ut any pre-hype,
people aren’t going to know about it.”

You should also need a powerful promo site in order for the people to know what your application
can do. Based on Getting Real, you need the following in order to have a powerful promo site.
The following are:

*  Overview: Explain your app and its benefits.
* Tour: Guide people through various features.
* Screen captures and videos: Show people what the app actually looks like and how to use it.
* Manifesto: Explain the philosophy and ideas behind it.
* Case Studies: Provide real life examples that show what’s possible.
* Buzz: Testimonial quotes from customers, reviews, press, etc.
* Forum: Offer a place for members of the community to help one another.
* Pricing & Sign-up: Get people into your app as quickly as possible.
* Weblog: Blogs keep your site fresh with news, tips, etc.

After doing all that, you now need to put up a site wherein people can enter their email
addresses if they are interested with the application. With that kind of foundation, you can
go rolling anytime. You can also put up a site where people can learn on how you came up with
the application.

Last but not the least, give your application a name wherein it will forever be stuck on
people’s minds. It should be a catchy one and easy to remember. Getting Real suggests that
it should’nt be too descriptive. The shorter, the catchier, the more memorable, THE BETTER!:)


Chapter 12 October 13, 2008

Filed under: Getting Real — hikaru011 @ 11:36 am
Tags: ,

Free Sample

Basically in order to attract customers, you should entice them. An example given in the reading is apple itunes. Itunes is free software that you can download in the internet. In this strategy, Apple also commercializes or advertises their product, I pod.

Easy On, Easy Off

From signing in and signing out from a site, it should be easy. Most people prefer fast and the simplest app.

Exit with Ease

Don’t hold users against their will. If they want to leave, let them pick up with all of the content they created while they were on your site and leave…for free… You have to let the barn door open and focus on keeping your customers fed, so they want to come back, instead of coming back because they’re stuck

Silly Rabbits, Tricks are for kids

Avoid long-term contracts, sign-up fees, etc

Don’t try to find “tricky” ways to get more cash. Earn it.

A Softer Bullet

When you are about to deliver bad news, make it as painless as possible by making plenty of advance notices.


Chapter 11 October 8, 2008

Filed under: Getting Real — hikaru011 @ 12:33 pm
Tags: ,

There’s Nothing Functional about a Functional Spec

Spec documentation is a blueprint or outline. A functional spec is said that it usually wind up having nothing to do with the finish product. They are not the real thing that you’ll be working on. It is just a piece of paper so there’s no need to spend so much time and effort making this.

Don’t do Dead Documents

Build, don’t write. Do not waste time on making documents that are unnecessary. It is just a waste of time.

No One’s Going to Read It

I can’t even count how many multi-page product specifications or business requirement documents that have languished, unread, gathering dust nearby my dev team while we coded away, discussing problems, asking questions and user testing as we went. I’ve even worked with developers who’ve spent hours writing long, descriptive emails or coding standards documents that also went unread.

Webapps don’t move forward with copious documentation. Software development is a constantly shifting, iterative process that involves interaction, snap decisions, and impossible-to-predict issues that crop up along the way. None of this can or should be captured on paper.

Don’t waste your time typing up that long visionary tome; no one’s going to read it. Take consolation in the fact that if you give your product enough room to grow itself, in the end it won’t resemble anything you wrote about anyway.

Tell me a quick story

Think strategy, not tactics. When you are about to write new features or concept of a product, it is better to write a brief story about it. Avoid using technical terms and making it as an outlined document. Use common terms that anyone can understand and appreciate.

Use Real Words

Lorem Ipsum Garbage

By not having the imagination to imagine what the content “might” be, a design consideration is lost. Meaning becomes obfuscated because “it’s just text”, understandability gets compromised because nobody realized that this text stuff was actually meant to be read. Opportunities get lost because the lorem ipsum garbage that you used instead of real content didn’t suggest opportunities. The text then gets made really small, because, it’s not meant to be used, we might as well create loads of that lovely white space.

Personify your product

Think of your product as a person. Keep these traits as the product is built.


Chapter 10

Filed under: Getting Real — hikaru011 @ 12:14 pm
Tags: ,

Less Software

“.. Keep your code as simple as possible.” When you keep on revising, the more complex and complicated your product will be. Remember that you have a scope and in that scope are the limitations and main purpose of your product.

  • Less software is easier to manage.
  • Less software reduces your codebase and that means
  • less maintenance busywork (and a happier staff).
  • Less software lowers your cost of change so you can adapt quickly. You can change your mind

without having to change boatloads of code.

  • Less software results in fewer bugs.
  • Less software means less support.

Optimize for happiness

It is important that when you work, people should be comfortable. When you use a language, you must think if your people can really work on it. If the workers are comfortable, they can write simply and readable codes. They can execute it properly and surely they can really do their job well.

Code Speaks

Listen up

“Don’t worry about design, if you listen to your code a good design will appear…Listen to the technical people. If they are complaining about the difficulty of making changes, then take such complaints seriously and give them time to fix things.”

Open Doors

“Don’t try to lock-in your customers. Let them get their information when they want it and how they want it.:


Chapter 9 October 1, 2008

Filed under: Getting Real — hikaru011 @ 9:23 am
Tags: ,

Interface First

Design your interface first. Basically start with what people are going to see and use. Designing it does not necessarily coding and doing it in the computer. You can use paper and pencil to come up with a design that people would love to see.

Epicenter Design

Start with what is really essential. In the example from the reading, when making a blog post, start working with the blog itself rather than doing the sidebars, headers, etc. Do the essentials first before the extras.

The three state solution

  • Regular
    The screen people see when everything’s working fine and your app is flush with data.
  • Blank
    The screen people see when using the app for the first time, before data is entered.
  • Error
    The screen people see when something goes wrong.

The Blank Slate

Here are some reasons why you need to include a blank slate:

  • Use it as an opportunity to insert quick tutorials and help blurbs.
  • Give a sample screenshot of the page populated with data so people know what to expect (and why they should stick around).
  • Explain how to get started, what the screen will eventually look like, etc.
  • Answer key questions that first-time viewers will ask: What is this page? What do I do now? How will this screen look once it’s full?
  • Set expectations and help reduce frustration, intimidation, and overall confusion.

Get Defensive

When you launch something, surely it goes under several testing. But the fact is customers can still encounter problems. The defensive design is somewhat compared to defensive driving. Defensive driving is when you keep any eye for any problems you might encounter while driving. Defensive design is like keeping an eye for any problem you can encounter that can cause visitors confusion and frustration.

Remember: Your app may work great 90% of the time. But if you abandon customers in their time of need, they’re unlikely to forget it.

Copywriting is Interface design

Good writing is good design. When you design, basically designs are not just animation, features, effects, pictures, etc. Letters are automatically involved. Some of the developers think that if they use jargon or highfaluting words, people may tend to think that they are unreachable. People can get confuse. Try using language that all of us can understand so that confusion won’t take place.

One interface

Most of the companies develop an admin screen, which is use for updating, edit, delete, etc. and the user screen, the one that people can visit. Having two different screens can encounter several problems like tax, etc. If you only have one screen that can be use, it is much better because the fewer screens you have to worry about, the better they’ll turn out.



Filed under: Getting Real — hikaru011 @ 8:40 am
Tags: ,

Hire Less and Hire Later

Small and even big companies don’t need that much people as they think. Let say you have the 100 best employees in the world, still you can’t say that your company would not encounter any problems. The training part and even how all these people can achieve harmony to work perfectly. When you fired someone or someone resigned for his job, don’t immediately search someone for replacement. Look at your people; if they can do the job well less one person, then you definitely do not need another one.

Kick the Tires

Ever heard of the term “test drive”? They say when you want to know the capacity of a person, take him out to the real world. When you see a potential team, give them the chance to work in the real world. Surely, you need to guide them, but thru this test drive you will know each of their capacity.

Actions, not Words

When hiring or promoting someone to be in a technical position, companies often look at resumes and references. But these are said to be silly in a lot of ways.

Open source is said to be the most efficient way when you want to hire technical people. With these, you can track someone’s work and contributions. You can judge them based on their works or their actions rather than what they say or their words.

Here are some important factors you need to look in when you want to hire the right people for a technical position:

  • 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.

Get well rounded individuals

Small teams can’t afford to have many employees. Any company doesn’t need to have workers who only specialized to one thing and doesn’t have any ideas one other things. Companies need to have someone who can do multi tasking. Well of course it can save them a lot of salary expenses but at the same time it can make their employees well rounded.

You can’t fake enthusiasm

It is better to hire an average happy individual rather than unhappy expert. Find someone who shows enthusiasm at work and eagerness to learn new ideas. Try to find someone who can definitely fit your team.


Hire good writers. Well it does not really matter if he is a programmer, analyst or developer. A good writer is also said to be a good communicator. Surely he can write what he thinks and feels and with these, he can definitely explain it verbally. A good writing leads to effective, concise code, email, etc.



Filed under: Getting Real — hikaru011 @ 8:35 am
Tags: ,


Most companies have different departments. Each department has specialization. It is true that if one has a smaller task, he can do it well and sometimes perfect. But it also creates a situation where staffers see just their own little world instead of the entire situation. The people or your workers should have unity in them so that they can create harmony. Having a harmony in the work area may avoid lack of knowledge and can lead to delivery of better performance.

Alone Time

Most of us get our work gone when we are not bothered by others, when we are in the mood. The alone time is when no one is bothering you and then you can do whatever your tasks are. We you get in the zone, it is where you are very passionate about what you are doing.

It is important that each of us have this “alone time”. In your work, give yourself like 4 hours to be alone. Shut up and start working. Receive no calls and text, talk to nobody. In this set up you can surely get your job done.

Meetings are Toxic

In every business or company, we often hear the word meeting. Business meeting occurs when there are certain factors in the business are not clear. Meetings usually take an hour or more. You can actually hear presentation of new projects, defenses and even debates. But after the talking part, that is the only time when people start working. Instead of spending an hour or more in dull meetings, try to use this time to go into action. Be productive.

Meetings are not avoidable. But it can be modified. Try communicating via YM or texting rather than spending time debating. Just be straight forward. If it is really necessary to meet personally, have a 30 minute meeting. Short and straight forward communication.

Seek and Celebrate small victories

When you are developing a new system, it just can’t be launch after a month. Only after you launched it, there you can celebrate. No one wants to just work their minds off 24/7. Of course each one of us needs to lighten up sometimes. Instead of waiting the product launching day, have some small victory celebration. For example, when you add a unique feature on your system, celebrate for it. At least you have this mini celebration to look forward to every time you get your job done.


site90.com September 24, 2008

Filed under: is ebiz — hikaru011 @ 11:00 am
Tags: ,

please do visit: http://hikaru011.site90.com/

thanks! ^-^


Chapter 6 September 22, 2008

Filed under: Getting Real — hikaru011 @ 9:39 am
Tags: ,

Race to Running Software

Running a software is said to be the best way to build momentum. The very first day, ideas should be formalized. You can even skip details, do less and even take short cuts as long as it can runs the software faster. “Running a software is real.”

The Real Thing Leads to Agreement

When a group of different people set out to try and find out what is harmonious…their opinions about it will tend to converge if they are mocking up full-scale, real stuff. Of course, if they’re making sketches or throwing out ideas, they won’t agree. But, if you start making the real thing, one tends to reach agreement.

Christopher Alexander, Professor of Architecture

Rinse and Repeat

You don’t need to aim for perfection on the first try because you know that you will do it again later. Learn from feedback and comments and then start perfecting your work.

From idea to implementation

In any projects, you definitely start with ideas. You think of a subject or topic. You let details flow into your mind. Together with your team, you are brainstorming.

When these ideas are being planned like how will you do t, when, where, etc. That is the time that you are sketching your ideas or you are now starting to plan it.

When creating a HTML screens, you should get something real posted so that anyone can see what it looks like on screen.

The coding part is where you code your ideas.

During this whole process remember to stay flexible and expect multiple iterations. You should feel free to throw away the deliverable of any particular step and start again if it turns out crappy. It’s natural to go through this cycle multiple times.

Avoid Preferences

Preferences are also evil because they create more software. More options require more code. And there’s all the extra testing and designing you need to do too. You’ll also wind up with preference permutations and interface screens that you never even see. That means bugs that you don’t know about: broken layouts, busted tables, strange pagination issues, etc.

We may think that customers see preferences as a blessing but the truth is, for a customer, having a lot of option are a headache. Be direct and straight. Just make a decision.


Done means you have completed something. It means something has already been accomplished. They said that think of it as a magical word. Yes, maybe because now your work is fully completed. It does not necessarily mean that you make all your decisions and work right. For now it may work but as soon as you realized that there is something wrong, you can actually go back and revise it.

Accept that decisions are temporary. Accept that mistakes will happen and realize it’s no big deal as long as you can correct them quickly. Execute, build momentum, and move on.

Test in the wild

There’s no substitute for real people using your app in real ways. Get real data. Get real feedback. Then improve based on that info.

Shrink your time

In doing your job, try to shrink or break down time frames into smaller chunks. Keep dividing it into smaller and smaller details and until you can handle it well.


Chapter 5 September 21, 2008

Filed under: Getting Real — hikaru011 @ 9:32 am
Tags: ,

Half, Not Half-Assed

Stick to what is really essential. Trim features down and basically you will come up with the most essential parts.

Start off with a lean, smart app and let it gain traction. Then you can start to add to the solid foundation you’ve built.

It Just Doesn’t Matter

Most of the time you spend is wasted on things that just don’t matter. If you can cut out the work and thinking that just don’t matter, you’ll achieve productivity you’ve never imagined.

Start With No

“We Don’t Want a Thousand Features”

Steve Jobs gave a small private presentation about the iTunes Music Store to some independent record label people. My favorite line of the day was when people kept raising their hand saying, “Does it do [x]?”, “Do you plan to add [y]?”. Finally Jobs said, “Wait wait — put your hands down. Listen: I know you have a thousand ideas for all the cool features iTunes could have. So do we. But we don’t want a thousand features. That would be ugly. Innovation is not about saying yes to everything. It’s about saying NO to all but the most crucial features.”

—-Derek Sivers, president and programmer, CD Baby and HostBaby
(from Say NO by default)

Hidden Costs

Expose the price of new features

Although the cost already passed the “no” stage, still you need to expose its hidden cost.

Can You Handle It?

Build something you can manage

In any business, it is important that everything you produced must be managed well.

Bottom line: Build products and offer services you can manage. It’s easy to make promises. It’s much harder to keep them. Make sure whatever it is that you’re doing is something you can actually sustain — organizationally, strategically, and financially.

Human Solutions

Make your software general so everyone can find their own solution. Give people just enough to solve their own problems their own way. People figured out how to solve issues on their own.

Do the best job you can with the root of the problem then step aside. People will find their own solutions and conventions within your general framework.

Forget Feature Requests

In forums, we often see customer’s requests like they think that a certain product can improve if they include this and that. But remember that the first response is “no”. Keep in mind that you have a vision and you must stick with it. Basically if a customer request is really essential, sooner or later it will bubble up and you can definitely know if it is really important.

Hold the Mayo

Ask people what they don’t want

Innovation Comes From Saying No

[Innovation] comes from saying no to 1,000 things to make sure we don’t get on the wrong track or try to do too much. We’re always thinking about new markets we could enter, but it’s only by saying no that you can concentrate on the things that are really important.

—Steve Jobs, CEO, Apple (from The Seed of Apple’s Innovation)


Chapter 4

Filed under: Getting Real — hikaru011 @ 8:47 am
Tags: ,

What’s the big idea?

The vision will guide your decisions and keep you on a consistent path. A vision should be brief and concise. One sentence would be enough but it should be direct to the point. Before you start designing or coding anything you need to know the purpose of your product, the vision.

Make Mantra

Organizations need guideposts. They need an outline; employees need to know each day when they wake up why they’re going to work. This outline should be short and sweet, and all encompassing: Why do you exist? What motivates you? I call this a mantra — a three or four-word description of why you exist.

Guy Kawasaki, author (from Make Mantra)

Ignore Details Early On

Success isn’t the only thing you’ll find in the details. You’ll also find stagnation, disagreement, meetings, and delays. These things can lower the chances of your success.

Try not to focus on details too early in the process. There’s plenty of time to be a perfectionist. You can do it later. You need to begin first to fix the functionality. Make sure it works. The design part can wait.

Details reveal themselves as you use what you’re building. You’ll see what needs more attention. You’ll feel what’s missing. You’ll know which potholes to pave over because you’ll keep hitting them. That’s when you need to pay attention, not sooner.

It’s a Problem When It’s a Problem

Don’t waste time on problems you don’t have yet

For example, do not worry if you lack programmers. If you think that you need 10 programmers but the truth is your 3 programmers are quite enough since you just started. Just don’t search problems in your company’s future life, just focus on its life today.

Bottom Line: Make decisions just in time, when you have access to the real information you need. In the meanwhile, you’ll be able to lavish attention on the things that require immediate care.

Hire the Right Customers

In any business, you need to have your target market. We often hear the saying that “ the customers are always right” but the truth is that the customer is not always right. The truth is you have to sort out who’s right and who’s wrong for your app.

If you try to please everyone, you won’t please anyone

Scale Later

The bigger problem isn’t scaling, it’s getting to the point where you have to scale.

Majority of web apps are never going to reach that stage, where millions of people are using it. If that time comes, well you will have time to adjust and respond to the problem.

Create a great app and then worry about what to do once it’s wildly successful

Make Opinionated Software

“Software should be agnostic”. Software should be flexible. But it is said that the best software has a vision. When someone uses software, they are not just looking for features, they looking for an approach. And if they don’t like your software, there is plenty of software that can suit their taste. Just do remember that you should stick with your vision.

Don’t go chasing people you’ll never make happy.


Chapter 3 September 14, 2008

Filed under: Getting Real — hikaru011 @ 7:02 am
Tags: , ,

The leaner you are, the easier it is to change.

Small companies have advantages over huge companies. Some small companies think of this as a disadvantage but the truth is, having a small company and lean mass is more efficient than having a big company and more mass. Small company can talk to their clients or customers more personal than huge companies that require formality when communicating with clients. Small company should be more friendly and personal so that they could differentiate themselves from big companies.

Being small, there are constraints and limitations, but let these be a guide or challenge. Small companies often have less people but this is not really considered as a main problem. As long as you have the right team it isn’t be a threat for your company.


Chapter 2 September 10, 2008

Filed under: Getting Real — hikaru011 @ 8:57 am
Tags: ,

Build less

It is said that to beat your competitors you need to one-up them. This one-upping state of mind is a dead-end. A defensive company can only think behind and not think ahead. They just follow.

To beat a competitor, do less. Try solving simple problems and leave the huge problems to others. Try downing instead of one-upping.

What’s Your Problem?

A great way to build software is to start solving your own problems.

When you are solving your problems, you create tools that you are passionate about. Passion means you’ll truly use it and care about it.

Fund Yourself

The first priority of many startups is acquiring funding from investors.

Outside Money is Plan B

But do remember that if you get your funds from outsiders you’ll have to pay them back and so expectations are raised.

I read about what Jake Walker, has started one company with investor money (Disclive) and one without (The Show), said as he discusses differences between two paths.

“The root of all the problems wasn’t raising money itself, but everything that came along with it. The expectations are simply higher. People start taking salary, and motivation is to build it up sell it, or find some other way for the initial investors to make their money back. In the case of the first company, we simply started acting much bigger than we were – out of necessity… “

Fix Time and Budget, Flex Scope

A way to launch on time and on budget is to keep them fixed. Never throw more time or more money at a problem, just scale back the scope.

If you can fit everything in within the time and budget allotted then don’t expand the time and budget.

Benefits of fixing time and budget:

  • Prioritization
  • Reality
  • Flexibility

Have an Enemy

Projects turn out better when everyone takes collective ownership of the process.

But do remember that it is important not get too obsessed with the competition. Overanalyzed other products and you’ll start to limit the way you think.

Its shouldn’t be a Chore

it should be your passion.

Enthusiasm manifests itself readily of course, but indifference is equally indelible. If your commitment doesn’t encompass a genuine passion for the work at hand, it becomes a void that is almost impossible to conceal, no matter how elaborately or attractively designed it is.

—Khoi Vinh


Chapter 1

Filed under: Getting Real — hikaru011 @ 8:13 am
Tags: ,

Getting Real

According to http://gettingreal.37signals.com/toc.php, Getting real is a smaller, faster, better way to build software. It is about skipping all the stuff that represent real and actually building the real thing. It’s cheaper. It is less in a way that less of everything that is not essential.

Getting real starts with the interface, the real screen that people are going to use. This lets us get the interface right before you get the software wrong. Basically it start backwards.

All in all, getting real delivers what the customers really need and eliminates anything that they don’t.

37 signals

37 signals is a small team that creates simple, focused software.

Basically 37 signals  build products that work smarter, feel better, allow you do things your way and it is easier to use.

Caveats, disclaimers, and other preemptive strikes

Getting Real, every now and then receive complaints. Here are responses to some complaints:

Getting Real is a system that’s worked terrifically for us. Many of these concepts have been around in one form or another for a long time. If you’re company runs on long term schedules with big team, there are still ways to get real. The first step is to have smaller units.


http://shoppersgalore.myshopify.com September 9, 2008

Filed under: is ebiz — hikaru011 @ 5:37 am
Tags: ,

Fashionista by Jimmy James

please do visit:


for products that suits unique teenage girl’s lifestyle. (“,)


Retail Blog # 1 September 20, 2009

Filed under: Vertsol — hikaru011 @ 11:28 am


Having this new kind of technology will benefit most of us. Barcode reader has been popular tool of technology ever since. I think with the invention of this new technology, barcode imager, will help us to appreciate more the usefulness of the machines that are often used when doing business transactions. Also, barcode imager has a lot to offer compared to the previous models of barcode readers.


Assignments and Exercises1 April 13, 2009

Filed under: webdevt — hikaru011 @ 10:08 am

List of works

sir nasira na po yun site90 ko pero nakablog po lahat ng gawa ko.


Michigan Alcohol Screening: SMA Otsuka, Hikaru

Filed under: webdevt — hikaru011 @ 9:58 am
Tags: ,

WEBDEVT FINALS: Michigan Alcohol Screening- SMA by Otsuka Hikaru

Facebook App



webdevt FINALS April 12, 2009

Filed under: webdevt — hikaru011 @ 8:38 am





Filed under: webdevt — hikaru011 @ 7:43 am


AS14 – Simplepie,   POPURL
EX6 – Credit Card Validator

EX5 – Poly9

AS17 – amCharts
AS19 – fb-style


amChart, Facelist, freepoly April 2, 2009

Filed under: webdevt — hikaru011 @ 4:00 am

Social Network Friends – amchart




amCharts April 1, 2009

Filed under: Uncategorized — hikaru011 @ 2:52 pm

amCharts –social networks friends