HaruTech

11 tips for better code

2010-12-23T00:15:00.002+08:00

There are several reasons why you should write clean and readable code. Most importantly, every code is written once, but read many times over and over. When you come back to your code next day, you have to read it. When you show your code to someone else, he has to read it. Thus by spending little more time with writing, you save A LOT of time when reading it again.

Lets see some of the basic rules

1.keep methods short
2.never ever ever reuse a variable for different purpose
3.use self-descriptive variable and method names
4.define variables as close as possible to the place of their usage
5.no magic numbers
6.be friend with your language
7.don’t fight the convention
8.watch out for premature optimization
9.always refactor the code after you test it
10.don’t get sucked into overengineering
11.learn new things by prototyping

Now, let’s look up at each point in more detail

1. Keep methods short
Even though many people obey this rule, it is still very important. Method should always fit on the screen. When you have to scroll, it takes away your concentration and you can’t see whole context. Optimal length is 5-20 lines, depending on the situation. Of course getters/setters are usually one-line methods, but they’re more like accessors than actual methods.

2. Never ever ever reuse a variable for different purpose
One variable should be used only for one purpose. By making variable constant (const in C++, final in Java), you also help the compiler with optimization and make your code scream This variable is not going to change, which makes the code a lot more readable.

3. Use self-descriptive variable and method names
Anyone should be able to understand your code by just looking at it. You should almost never use abbreviations, except for the most idiomatic ones like

src - source
pos - position
prev - previousIf you think writing descriptive names is not worth the time, just compare
n, ns, nsisd
with
numTeamMembers, seatCount, numSeatsInStadium

4. Define variables as close as possible to the place of their first usage
While building a house, you don’t want your hammer to be on the other side of the yard. Instead, you keep your tools as close as possible. The same applies to variables.

int foo = 3;
int bar = 5;
// bunch of code that use "bar"
// but doesn't care about "foo"
// ...

baz(foo);This could be easily refactored to

int bar = 5;
// bunch of code that use "bar"
// but doesn't care about "foo"
// ...

int foo = 3;
baz(foo);This becomes a real issue when the code between declaration and first usage is very long (more than one screen). It is much harder to keep the context in your mind, when you have to scroll a lot to find out what given variable is.

5. No magic numbers
Whenever you compare something against constant value, it should be defined as constant. There is nothing worse than debugging your teammate’s code with things like

il < 4384What about this instead?

inputLength < MAX_INPUT_LENGTH

6. Be friend with your language
Learning new language is always fun, you can learn to do things in new cool way. There is one big downside of being pro in one language while learning other one though. Say you’re Java developer trying to learn Ruby. You should learn how to do things the Ruby way, instead of trying to apply your skill in doing things the same way you’d do them in Java.

You need to write 5 times “Hello world!”. In Java, you would do something like.

for (int i = 0; i < 5; i++) {
System.out.println("Hello world!");
}In Ruby, you might be tempted to write

for i in (0..5)
puts "Hello world!"
endWhich seems OK, but there is a much better way

5.times { puts "Hello world!" }
7. Don’t fight the convention
Many languages have many different conventions. In general, people most probably know is Code Conventions for Java. Lets look at some of those conventions.

◦method names should always begin with lower-case letter, followed by CamelCase (veryLongVariableName)
◦class names should always be in CamelCase
◦constant names should be all in upper case with underscores (MY_CONSTANT)
◦open brace should be on the same line as if condition
Breaking any of conventions should have a valid reason, never do it just because you don’t like it. If you decide to change some convention inside your team, that’s OK, but you might have problem when sharing code with other not so enlightened programmers.

8. Watch out for premature optimization
Premature optimization is root of all evil, at least that’s what TV said … First thing you should care about is to write understandable code. It doesn’t have to be fast the first time you write it.

All optimization is premature unless the program is slow. If you want to optimize something, at first you need to find out where the problem is. Thats why we have profilers.

Trying to optimize something without finding source of the problem always ends up in breaking something, or at least your code may turn out to be unreadable. If you think that something is slow, don’t just blindly start rewriting the code, find a proof first.

Don’t solve problems that don’t exist.

9. Always refactor the code after you test it
Nothing is perfect. Even though you might think you’re writing a perfect code, try looking at it few months later. You will probably fell like “wtf is that?”.

Good way to improve the quality of your code is to refactor it after you test it. By testing I mean assuring that it works, which can be done either automatically or manually.

First of all, you need your code to work. Don’t write it perfect the first time, just make it work. Then refactor it to make it perfect. For those of you that know something about Test Driven Development, this might seem very familiar. The key here is to get used to the whole refactoring thing. If you’re using powerful IDE like IntelliJ IDEA, your life will be a lot easier while refactoring.

After you try refactoring, you will probably make a mistake and break something. That’s why it is good to write automated tests. Any time you refactor, you can just run all test suites and see exactly what went wrong.

10. Don’t get sucked into overengineering
When I first read about design patterns, I thought I found The Holy Grail. It all seems to be thought out, working perfectly and making design easy to understand, because you can just say “I used an observer pattern”, instead of explaining it all.

So where is the problem? Because it all looks so natural and easy, you start using design patterns for everything. Why not make this class singleton? And what about creating another factory?

Then instead of writing simple 80 line script, you end up with 10 class + 15 interface monster with bunch of generics and annotations, where 97% of the code doesn’t do anything.

Design patterns are very useful tool to simplify the design, which doesn’t mean using them everywhere you can. You should use them, but don’t abuse them.

11. Learn new things by prototyping
Programming is all about learning new things. When you learn new library or language, you suddenly have the urge to throw away all old code and rewrite it from scratch. There are lots of reasons why you don’t want to do that.

Adding a new library or framework to existing application is a similar problem. Say you’re writing a javascript web application, and in the middle of everything, you discover jQuery. Now you have sudden urge to throw away all your javascript and write it in jQuery, even though you haven’t used it yet.

The best way to go is to first create a lot of simple things with jQuery, where you will learn all the stuff you need in your application. You need AJAX? Try it on simple example outside the project and after you fully understand it, throw it away and move into production.

If you are serious about programming, I strongly recommend reading Code Complete by Steve McConnell. It will forever change the way you think about programming :)

Begginers guide to Visual Studio LightSwitch

2010-12-12T16:23:00.005+08:00

Here are the links for the tutorial enjoy

Part1

Part2

Part3

Part4

Google's Going Native in Chrome With SDK

2010-05-16T12:03:00.000+08:00

Google is accelerating its effort this week to bring more powerful and fully functioned applications to the Web with the release of the Native Client SDK preview.

Native Client is an open source technology that enables native C or C++ code to run in a Web browser, bringing more advanced applications to the Web that can run inside of Google's Chrome browser.

The approach extends the capabilities of Web-based applications beyond the limitations imposed by using JavaScript, and the SDK builds on efforts to promote the technology that Google has had underway since last year.

"When we released the research version of Native Client a year ago, we offered a snapshot of our source tree that developers could download and tinker with, but the download was big and cumbersome to use," David Springer, a senior software engineer at Google, wrote in a blog post. "The Native Client SDK preview, in contrast, includes just the basics you need to get started writing an app in minutes."

With the new SDK, Google is providing a GCC-based compiler for C and C++ source code as well as samples to help developers build native-code-compliant applications.

One concern that has been raised about Native Client is its portability: JavaScript is available for multiple browsers, while Native Client is being developed by Google and currently works only for Chrome.

"Native Client seems like a huge leap backwards to me," a commenter using the alias "Guspaz" wrote in response to the Native Client blog post. "Why would anybody want to use Native Client when it will prevent your app from running on a variety of platforms such as older Macs, smartphones, tablets, and even smartbooks (including ChromeOS) that run PowerPC or ARM processors? I'm just not seeing the point here."

As it turns out, portability is a key theme for Native Client development, according to Google. Henry Bridge, Google's product manager for Native Client, responded to concerns about lock-in by noting that Google is deeply committed to building a system that's platform-neutral. That said, Bridge admitted that Google has yet to ship a neutral-platform format for the SDK, or an ARM compiler either. He added that Google has no plans to build a compiler for PowerPC.

The Native Client effort also runs in parallel to another Google initiative. To date, the company's developers have spent time and effort on building the V8 JavaScript engine to help accelerate Web applications. In another comment, Bridge noted that Native Client is different than V8 in that it doesn't interpret JavaScript at all, but rather is focused entirely on native code.

"So why don't these compete? Because we think there are parts of Web apps people want to build in JavaScript and some parts of Web apps people want to build in other languages," Bridge wrote. "Take our video editing example. I'd rather build most of my UI and features in JS -- it's easier and will be just as responsive. But when I want to do the actual editing of the video data, which requires bit operations, etc., I'd rather do that in C++: Working with binary data is easier
in C++, and will certainly be faster."

Sean Michael Kerner is a senior editor at InternetNews.com, the news service of Internet.com, the network for technology professionals.

Guarding against database anti-forensics

2010-05-08T16:32:00.004+08:00

Database hacking has gone mainstream and is becoming harder to detect because of the increasingly sophisticated anti-forensic procedures hackers use to cover their tracks.

Knowing forensics inside and out, as well as the tricks hackers use to foil forensics, is essential for professionals responsible for protecting the integrity of corporate data.

Privilege Made Simple. Privilege Identity Management (PIM) Demystified: Download nowDatabases contain a high percentage of confidential data, yet many organizations lack the budget and management buy-in to implement protections. According to studies, 60% of organizations have experienced a breach in the past 12 months, 80% expect database attacks to increase and 40% on average fail security audits.

There are plenty of tools to help thwart attacks -- such as vulnerability management products that include vulnerability assessment and user monitoring functionality -- but the trick is to deploy comprehensive solutions that help in forensics and provide visibility into how attackers cover their tracks.

The 30 skills every IT person should have

2008-07-02T21:05:00.001+08:00

1. Be able to fix basic PC issues. These can be how to map a printer, back up files, or add a network card. You don't need to be an expert and understand how to overclock a CPU or hack the registry, but if you work in IT, people expect you to be able to do some things.

[ If you have IT staffers who aren't up to snuff, fire them. Learn how to do it right. ]

2. Work the help desk. Everyone, from the CIO to the senior architect, should be able to sit down at the help desk and answer the phones. Not only will you gain a new appreciation for the folks on the phones, but you will also teach them more about your process and avoid escalations in the future.

3. Do public speaking. At least once, you should present a topic to your peers. It can be as simple as a five-minute tutorial on how IM works, but being able to explain something and being comfortable enough to talk in front of a crowd is a skill you need to have. If you are nervous, partner with someone who is good at it, or do a roundtable. This way, if you get flustered, someone is there to cover for you.

4. Train someone. The best way to learn is to teach.

5. Listen more than you speak. I very rarely say something I didn't already know, but I often hear other people say things and think, "Darn, I wish I knew that last week."

6. Know basic networking. Whether you are a network engineer, a help desk technician, a business analyst, or a system administrator, you need to understand how networks work and simple troubleshooting. You should understand DNS and how to check it, as well as how to ping and trace-route machines.

7. Know basic system administration. Understand file permissions, access levels, and why machines talk to the domain controllers. You don't need to be an expert, but knowing the basics will avoid many headaches down the road.

8. Know how to take a network trace. Everyone in IT should be able to fire up wireshark, netmon, snoop, or some basic network capturing tool. You don't need to understand everything in it, but you should be able to capture it to send to a network engineer to examine.

9. Know the difference between latency and bandwidth. Latency is the amount of time to get a packet back and forth; bandwidth is the maximum amount of data a link can carry. They are related, but different. A link with high-bandwidth utilization can cause latency to go higher, but if the link isn't full, adding more bandwidth can't reduce latency.

10. Script. Everyone should be able to throw a script together to get quick results. That doesn't mean you're a programmer. Real programmers put in error messages, look for abnormal behavior, and document. You don't need to do that, but you should be able to put something together to remove lines, send e-mail, or copy files.

11. Back up. Before you do anything, for your own sake, back it up.

12. Test backups. If you haven't tested restoring it, it isn't really there. Trust me.

13. Document. None of the rest of us wants to have to figure out what you did. Write it down and put it in a location everyone can find. Even if it's obvious what you did or why you did it, write it down.

14. Read "The Cuckoo's Egg." I don't get a cut from Cliff Stoll (the author), but this is probably the best security book there is -- not because it is so technical, but because it isn't.

15. Work all night on a team project. No one likes to do this, but it's part of IT. Working through a hell project that requires an all-nighter to resolve stinks, but it builds very useful camaraderie by the time it is done.

16. Run cable. It looks easy, but it isn't. Plus, you will understand why installing a new server doesn't really take five minutes -- unless, of course, you just plug in both ends and let the cable fall all over the place. Don't do that -- do it right. Label all the cables (yes, both ends), and dress them nice and neat. This will save time when there's a problem because you'll be able to see what goes where.

17. You should know some energy rules of thumb. For example: A device consuming 3.5kW of electricity requires a ton of cooling to compensate for the heat. And I really do mean a ton, not merely "a lot." Note that 3.5kW is roughly what 15 to 20 fairly new 1U and 2U servers consume. One ton of cooling requires three 10-inch-round ducts to handle the air; 30 tons of air requires a duct measuring 80 by 20 inches. Thirty tons of air is a considerable amount.

18. Manage at least one project. This way, the next time the project manager asks you for a status, you'll understand why. Ideally, you will have already sent the status report because you knew it would be asked for.

19. Understand operating costs versus capital projects. Operating costs are the costs to run the business. Capital equipment is made of assets that can have their cost spread over a time period -- say, 36 months. Operating costs are sometimes better, sometimes worse. Know which one is better -- it can make a difference between a yes and no.

20. Learn the business processes. Being able to spot improvements in the way the business is run is a great technique for gaining points. You don't need to use fancy tools; just asking a few questions and using common sense will serve you well.

21. Don't be afraid to debate something you know is wrong. But also know when to stop arguing. It's a fine line between having a good idea and being a pain in the ass.

22. If you have to go to your boss with a problem, make sure you have at least one solution.

23. There is no such thing as a dumb question, so ask it ... once. Then write down the answer so that you don't have to ask it again. If you ask the same person the same question more than twice, you're an idiot (in their eyes).

24. Even if it takes you twice as long to figure something out on your own versus asking someone else, take the time to do it yourself. You'll remember it longer. If it takes more than twice as long, ask.

25. Learn how to speak without using acronyms.

26. IT managers: Listen to your people. They know more than you. If not, get rid of them and hire smarter people. If you think you are the smartest one, resign.

27. IT managers: If you know the answer, ask the right questions for someone else to get the solution; don't just give the answer. This is hard when you know what will bring the system back up quickly and everyone in the company is waiting for it, but it will pay off in the long run. After all, you won't always be available.

28. IT managers: The first time someone does something wrong, it's not a mistake -- it's a learning experience. The next time, though, give them hell. And remember: Every day is a chance for an employee to learn something else. Make sure they learn something valuable versus learning there's a better job out there.

29. IT managers: Always give people more work than you think they can handle. People will say you are unrealistic, but everyone needs something to complain about anyway, so make it easy. Plus, there's nothing worse than looking at the clock at 2 p.m. and thinking, "I've got nothing to do, but can't leave." This way, your employees won't have that dilemma.

30. IT managers: Square pegs go in square holes. If someone works well in a team but not so effectively on their own, keep them as part of a team.

special thanx to http://www.infoworld.com for this info and of course code project for sending me the link :P

Disc Encryption

2008-02-25T19:16:00.002+08:00

while serving the net, i come to find tt most disc encryption can be easily break

Whenever a laptop containing lots of private data is lost, there are calls for 'disk encryption' that encodes all of a computer's data to become standard practice. But a dramatic new result by security researchers at Princeton suggests it is no panacea.

They've shown that a computer's RAM - short term memory - can give it away.

RAM needs power to hold data; but the researchers have found that information can persist for up to minutes after the power is cut. That's long enough to extract the key needed to unscramble the encrypted disk, which is always kept in a computer's RAM.

An accessible video (below or here) explains the team's findings in more detail. And you can read more at a website set up to explain the work

The RAM in most computers can hold information for a few seconds to a minute after power down. But cooling the RAM chip can extend that to up to ten minutes. Another video shows how an image held in RAM slowly degrades after the power is turned off.

The attack works on any laptop powered up, or in sleep/hibernate mode. Some machines using Microsoft Vista's BitLocker disk encryption are even vulnerable when switched off completely. Apple's FileVault and popular disk encyption software TrueCrypt suffer the same problem.

Since lots of sensitive data is carried around on entirely un-encrypted formats you could argue this is of little consequence. Properly safeguarding such data is more of a policy than a technical problem. Nevertheless, it will be interesting to see how long before this new attack appears 'in the wild', if at all.

Tom Simonite, online technology reporter

i got this article of http://www.newscientist.com/
special thanks to them for this article

Basic to Operating System

2008-02-06T15:55:00.000+08:00

Operating system types

As computers have progressed and developed so have the types of operating systems. Below is a basic list of the different types of operating systems and a few examples of Operating Systems that fall into each of the categories. Many computer Operating Systems will fall into more than one of the below categories.

GUI - Short for Graphical User Interface, a GUI Operating System contains graphics and icons and is commonly navigated by using a computer mouse. See our GUI dictionary definition for a complete definition. Below are some examples of GUI Operating Systems.

System 7.x
Windows 98
Windows CE

Multi-user - A multi-user Operating System allows for multiple users to use the same computer at the same time and/or different times. See our multi-user dictionary definition for a complete definition for a complete definition. Below are some examples of multi-user Operating Systems.

Linux
Unix
Windows 2000

Multiprocessing - An Operating System capable of supporting and utilizing more than one computer processor. Below are some examples of multiprocessing Operating Systems.

Linux
Unix
Windows 2000

Multitasking - An Operating system that is capable of allowing multiple software processes to run at the same time. Below are some examples of multitasking Operating Systems.

Unix
Windows 2000

Multithreading - Operating systems that allow different parts of a software program to run concurrently. Operating systems that would fall into this category are:

Linux
Unix
Windows 2000

J2EE Struts 2.0 Guide

2007-11-19T21:33:00.000+08:00

Strut guide & diff between strut 1 & 2

Struts 2 Architecture
Struts and webwork has joined together to develop the Struts 2 Framework. Struts 2 Framework is very extensible and elegant for the development of enterprise web application of any size. In this section we are going to explain you the architecture of Struts 2 Framework

Struts 1.x Vs Struts 2.x
In the following section, we are going to compare the various features between the two frameworks. Struts 2.x is very simple in comparison to the struts 1.x, few of its excelling features are:

Writing Jsp, Java and Configuration files
In this section we will write JSP, Java and required configuration files for our Struts 2 Hello World application. Now in struts 2 struts.xml is used to configure the applications. We will also deploy and test the application.

Struts 2 Actions Example
When a client request matches the action's name, the framework uses the mapping from struts.xml file to process the request.

Struts 2 Actions Introduction
When a client request matches the action's name, the framework uses the mapping from struts.xml file to process the request. The mapping to an action is usually generated by a Struts Tag.

Struts 2 Redirect Action
In this section, you will get familiar with struts 2 Redirect action and learn to use it in the struts 2 application.

more tutorials at http://www.roseindia.net/struts/struts2/