Y2K38 Bug

As we all are famailiar with the millenium bug Y2K i.e. the ‘Year 2000 Software Problem’. Y2K was the major problem to the software industry in that year. Because many systems were using last two digits of the year (like 97, 98, 99 etc.) for some date and time related processing, everyone was worried about the time 12:00:00 a.m. on or after 1 January 2000 because at that time, year 2000 and year 1900 would be executed as same.

Now, after that problem, there is another software bug ahead which needs a large attention towards it. The problem is said to be executed on Tuesday, 19th January 2038 and when the time will reach at 03:14:07 a.m. Many systems would fail to work after this time. Time after this moment will be stored automatically as negetive number and these systems will show the time of year 1901 rather than year 2038. Scientists and engineers called it ‘Y2K38 bug’. The systems and the softwares, which store their system time as signed 32 bit integer, would be affected by this problem. Many 32 bit systems, like Unix systems, store and manipulate the time in 32 bit binary format, and for this reason, it is also called as ’Unix Millenium Bug’. These systems use a data type of C language ‘time_t’ to store and display the time units. The ‘time_t’ is an integer data type and it stores the number of seconds since 12:00:00 a.m, January 1, 1970. Thus, on the date 1 Jan 1970 at 12:00:00 a.m. the value of this data type (time_t) was stored as 0. On the same date, at time 12:00:01 a.m. this value was 1. Furthermore, at time 12:01:00 a.m. this value was 60 (i.e. no. of seconds). Similarly, on January 2, 1970 at 12:00:00 a.m. the value stored was 3600. Moving on to its value on 19 January, 2038 as the moment reaches to 03:14:07 a.m. , the value of ’time_t’ will be ‘2147483647′ which was the highest value of 32 bit signed binary number. And just after one second, IT world will face this huge disaster. Value to time_t will start to decrease and the time shown by the systems will be 08:45:52 p.m. Friday December 13th, 1901. The problem will be more evident from the following figure.

Resources: Year 2038 Problem : Unix Millenium Bug

Continuous integration with Hudson

Continuous integration has become common practice for teams focused on ensuring code quality throughout the software development lifecycle. In this article, Nicholas Whitehead introduces Hudson, a popular open source CI server.

Continuous integration (CI) is a set of practices intended to ease and stabilize the process of creating software builds. CI assists development teams with the following challenges:

• Software build automation: With CI, you can launch the build process of a software artifact at the push of a button, on a predefined schedule, or in response to a specified event. If you want to build a software artifact from source, your build process is not bound to a specific IDE, computer, or person.
• Continuous automated build verification: A CI system can be configured to constantly execute builds as new or modified source code is checked in. This means that while a team of software developers periodically checks in new or modified code, the CI system continuously verifies that the build is not being broken by the new code. This reduces the need for developers to check with each other on changes to interdependent components.
• Continuous automated build testing: An extension of build verification, this process ensures that new or modified code does not cause a suite of predefined tests on the built artifacts to fail. In both build verification and testing, failures can trigger notifications to interested parties, indicating that a build or some tests have failed.
• Post-build procedure automation: The build lifecycle of a software artifact may also require additional tasks that can be automated once build verification and testing are complete, such as generating documentation, packaging the software, and deploying the artifacts to a running environment or to a software repository. In this way artifacts can quickly be made available to users.

To implement a CI server you need, at minimum, an accessible source code repository (and the source code in it), a set of build scripts and procedures, and a suite of tests to execute against the built artifacts. Figure 1 outlines the basic structure of a CI system.

Figure 1. Basic structure of a CI system

The system components come into play in the following sequence:

1. Developers check new and modified code into the source code repository.
2. The CI server creates a dedicated workspace for each project. When a new build is requested or scheduled, the source is retrieved from the repository into this workspace, where the build is then executed.
3. The CI server executes the build process on the newly created or refreshed workspace.
4. Once the build completes, the CI server can optionally invoke the defined test suite on the new artifacts. If the build fails, registered individuals can be notified by email, instant messaging, or some other method.
5. If the build is successful, the artifacts are packaged and transmitted to a deployment target (such as an application server) and/or stored as a new versioned artifact in a software repository. This repository can be part of the CI server, or could be an external repository, such as a file server or a software distribution site like Java.net or SourceForge. The source code repository and the artifact repository can be separate, and it is actually possible to use some CI servers without any formal source control system at all.
6. CI servers usually have some sort of console where projects can be configured and debugged, and where requests can be issued for operations such as ad hoc immediate builds, report generation, or retrieval of built artifacts.

Hudson is a free and open source product hosted at Java.net It was originally written by Kohsuke Kawaguchi, a staff engineer at Sun Microsystems, who announced its release on his blog in February of 2005. Hudson has since had approximately 154 releases.

Here are some of the reasons why I like Hudson, and why I would recommend it to you, barring any unusual requirements:

• Of all the CI products I've used, it is by far the easiest to install and configure.
• Its Web-based user interfaces are very friendly, intuitive, and responsive, in many cases providing immediate Ajax-enabled feedback on individual configuration fields.
• Hudson is Java-based (which is useful if you're a Java developer) but is not limited to building Java-based software.
• Hudson is cleanly componentized and offers a well-defined and documented extensibility API in the form of Hudson plugins. This has in turn led to a large library of Hudson plugins that extend the functionality of the server; these are freely available and installable from the Hudson console.

Resources:
- Get the latest Hudson WAR file here or here.
- Download apache-tomcat-6.0.18.exe to install Tomcat on your Windows machine. Download JBoss 4.2.3.GA for a Linux environment (look for the file named jboss-4.2.3.GA.zip).
- If your Hudson server cannot connect to outside resources, you can download the plugins you need from the Hudson Website.

Update your Resume!

What you say? You like your job? Have no intention of leaving? Why would I update my resume?

Well, I too enjoy my job and the company I work for. I’m not talking about finding a new job, I’m talking about managing your career. In this day and age, individuals need to take responsibility for career management.

A good time to review your resume is once a year, around review time. I know not all companies do yearly reviews. Maybe the review you get is not as valuable as it could be. Regardless, set up your own time to review your career progress.

From now on, update it so it reflects your current experiences. Take a good look at the what you have done in the past year. How have you progressed over the last couple years?

Next, set up some goals for yourself in the next year. I like to focus on four general areas:

Technology: What technologies should I make improvements on? What new technologies are coming up? How can I better use current technologies?

Processes: Learn about new agile methods? Learn about how others are using the methods and improving them. Learn a process you may be less familiar with like configuration management techniques.

People skills: Don’t forget the soft skills. I’m not necessarily talking management here (unless that is your goal). Leadership can come from anywhere. Unless you are a “one programmer team” you work with others. Whenever you are attempting to influence someone, you are using leadership skills.

Business: We don’t work in a vacuum. What business is my company in? What areas of that business can I get a greater understanding?

Once you have a list of general topics you want to focus on, make then concrete. Pick enough that pushes you to grow in the next year, but not more then you can effectively commit to.

Next, make each goal measurable. Write down something that you can do in the next year. Write the goal such that it is obvious when you done.

Put a date with the goal. If the goal has multiple parts, put dates to the sub goals as well. For example:

Technology goal: Attain a greater understanding in .NET framework.

• Read the book by
• Choose an application in which to use your new skills by
• etc…

People skills goal: Improve communication skills.

• Choose a topic you can present on by
• Prepare a presentation by
• Learn foreign languages: Japanese ...
  
• Present to your peers at a lunch-n-learn by
• etc..

Next year, you can review the goals you accomplished and add them to your resume.

These goals don’t all have to be specific to the company you work for. It makes sense that they are so you can improve your career opportunities there. However, add some personal goals as well. I might want to learn a new language like Groovy or Python even though my company is a primarily a Microsoft shop or learn the.NET framework if your company is a Java shop.

You have to take charge of your career. Your company may or may not take an active role in this. Like many things in life, if you don’t manage it, it will most certainly manage you.

What It Takes To Be A Great Technical Lead

Most teams have some kind of technical lead in place. They’re often referred to as the ‘dev lead’, or the ‘lead developer’ or the ‘lead programmer’ or whatever. Some people are great fits for this role, and some simply aren’t. Below is my list of what i think makes for a great technical lead. Note: i’m not claiming that i live up to all of this, although i do try to.

• You obviously need strong technical skills. You are responsible for the final result, so you better make sure that there is a solid technical foundation for the team to build upon. This doesn’t mean that you should build this foundation entirely yourself. Preferably, you involve your teammates into this as much as possible. You’re also responsible for fixing technical issues that your teammates can’t solve. You either fix it, or when that’s not possible you should figure out an acceptable workaround. Be sure that your teammates are fully aware of the details of the solution or the workaround.

• You have to be able to teach your teammates. As a technical lead it is your duty to improve the skills of your teammates. No matter how good you may be, if you can’t transfer that knowledge and those skills, you’re not doing a good job as a technical lead. If there are some core principles or practices that you want them to apply to their work, you need to make sure that each and every one of them really ‘gets’ it. You need to be willing to invest the time and effort it takes to achieve that.

• You need to trust your teammates. This isn’t always easy, especially when it’s about someone who hasn’t progressed as far or as fast as you would’ve liked him to. But it is definitely necessary. If a teammate realizes that you trust him, he will usually respond with improved output. It might not always be everything you hoped for… but either his effort, or the quality of the work will improve. Keep trusting the teammate, and eventually both will improve. Which actually happens a lot sooner than most people would think.

• Stimulate self-organization. I know a lot of people don’t believe in self organizing teams. And to an extent, that disbelief is somewhat valid. There always has to be one or a couple of people who have some kind of leadership role (be it officially or not). Those leadership roles do not prevent self organizing teams though, in fact, i’d say they enable them. Do not simply assign tasks to your teammates all the time. Organize planning meetings where members can choose the tasks they will do. Make sure there is always some kind of balance though. You really need to prevent that person A always gets the shitty tasks or that person B always get the funnest tasks. Mix it around it a little and try to make sure that the fun/shit ratio is never out of whack.

• Don’t keep the coolest technical tasks for yourself. If the project requires some kind of technical research to use a new library or to figure out an approach to a new problem or whatever, make sure all of the teammates get the chance to do these kind of things once in a while. It’s not always possible to do so, but when you can, it really pays off. Morale goes up, trust goes up in both directions, and everybody improves.

• Try to prevent overtime as much as possible. If you’ve been given an impossible deadline, try to convince management that it’s simply not doable. Fight for it if you must. But realistically speaking, you can’t extend every deadline they throw at you, and sooner or later you’re gonna be in a situation where you and your teammates are going to have to put in some overtime to get everything done on time. Don’t tell your teammates they have to do it. Ask them if they want to do it. For some people, this doesn’t always make a difference but for others, it makes a huge difference. And this one is very important when you’re doing overtime: do not go home early while your teammates are still working, because it will come back to bite you in the ass eventually.

• Remember that you are responsible for the final result. If something goes wrong, it really is your fault. Never put the blame on one of your teammates. Not within the team, and definitely not when managers are present. If a teammate screwed up and the problem made it into the production version, then that is your responsibility and your fault.

• Give credit where credit is due. If a teammate did a great job with something, give them that credit and make sure everyone else knows about it too, especially management. Never take credit for the work of a teammate because that is simply one of the lowest possible things you could do.

• Finally, you need to realize that your teammates are not your developers. I’ve often heard technical leads say things like “yeah, my developers…” or “my guys … “. No. They are your teammates, no matter what your role in the team is. Having a leadership role does not mean you are the boss of your teammates or that you can boss them around. If anything, it destroys morale and the results of your team will suffer tremendously from it.

Resources: Davy Brion

Android Development Flow

This diagram shows how Java source code, XML files, and other resources are compiled and packaged into an Android package file. The resulting .apk file is actually a JAR file, you can see its content by typing jar -tvf MyApp.apk.

• The yellow rounded rectangles are Android SDK tools
• The orange boxes are files created by the programmer
• The remaining white boxes are generated by the tools

Resources: Eric M. Burke

15 Tools to Help You Develop Faster Web Pages

Response times, availability, and stability are vital factors to bear in mind when creating and maintaining a web application. If you’re concerned about your web pages’ speed or want to make sure you’re in tip-top shape before starting or launching a project, here’s a few useful, free tools to help you create and sustain high-performance web applications.

I’ve tried to include a wide variety of tools that are easy to use, and have tried to keep them as OS and technology-independent as possible so that everyone can find a tool or two.

1. YSlow for Firebug

YSlow grades a website’s performance based on the best practices for high performance web sites on the Yahoo! Developer Network. Each rule is given a letter grade (A through F) stating how you rank on certain aspects of front-end performance. It’s a simple tool for finding things you can work on such as reducing the number of HTTP request a web page makes, and compressing external JavaScript and CSS files. A worthwhile read is the Ajax performance analysis post on IBM developerWorks that outlines practical ways of using YSlow in your web applications.

2. Firebug

Firebug is an essential browser-based web development tool for debugging, testing, and analyzing web pages. It has a powerful set of utilities to help you understand and dissect what’s going on. One of the many notable features is the Net (network”) tab where you can inspect HTML, CSS, XHR, JS components.

3. Fiddler 2

Fiddler 2 is a browser-based HTTP debugging tool that helps you analyze incoming and outgoing traffic. It’s highly customizable and has countless of reporting and debugging features. Be sure to read the “Fiddler PowerToy - Part 2: HTTP Performance” guide on the MSDN which discusses functional uses of Fiddler including how to improve “first-visit” performance (i.e. unprimed cache), analyzing HTTP response headers, creating custom flags for potential performance problems and more.

4. Cuzillion

Cuzillion is a cool tool to help you see how page components interact with each other. The goal here is to help you quickly rapidly check, test, and modify web pages before you finalize the structure. It can give you clues on potential trouble-spots or points of improvements. Cuzillion was created by Steve Saunders, the ex-Chief Performance at Yahoo!, a leading engineer for the development of Yahoo’s performance best practices, and creator of YSlow.

5. mon.itor.us

monitor.us is a free web-based service that grants you a suite of tools for monitoring performance, availability, and traffic statistics. You can establish your website’s response time and set up alerts for when a service becomes unavailable. You can also set-up weekly, automated benchmarks to see if changes you’ve made impact speed and performance either positively or negatively.

6. IBM Page Detailer

The IBM Page Detailer is a straightforward tool for letting you visualize web components as they’re being downloaded. It latches onto your browser, so all you have to do is navigate to the desired site with the IBM Page Detailer open. Clicking on a web page component opens a window with the relevant details associated with it. Whenever an event occurs (such as a script being executed), the tool opens a window with information about the processes.

7. Httperf

Httperf is an open-source tool for measuring HTTP server performance running on Linux. It’s an effective tool for benchmarking and creating workload simulations to see if you can handle high-level traffic and still maintain stability. You can also use it to figure out the maximum capacity of your server, gradually increasing the number of requests you make to test its threshold.

8. Pylot

Pylot is an open-source performance and scalability testing tool. It uses HTTP load tests so that you can plan, benchmark, analyze and tweak performance. Pylot requires that you have Python installed on the server - but you don’t need to know the language, you use XML to create your testing scenarios.

9. PushToTest TestMaker

PushToTest TestMaker is a free, open-source platform for testing scalability and performance of applications. It has an intuitive graphical user interface with visual reporting and analytical tools. It has a Resource Monitor feature to help you see CPU, memory, and network utilization during testing. The reporting features let you generate graphs or export data into a spreadsheet application for record-keeping or further statistics analysis.

10. Wbox HTTP testing tool

Wbox is a simple, free HTTP testing software released under the GPL (v2). It supports Linux, Windows, and MacOS X systems. It works by making sequential requests at desired intervals for stress-testing. It has an HTTP compression command so that you can analyze data about your server’s file compression. If you’ve just set up a virtual domain, Wbox HTTP testing tool also comes with a command for you to test if everything’s in order before deployment.

11. WebLOAD

WebLOAD is an open-source, professional grade stress/load testing suite for web applications. WebLOAD allows testers to perform scripts for load testing using JavaScript. It can gather live data for monitoring, recording, and analysis purposes, using client-side data to analyze performance. It’s not just a performance tool – it comes with authoring and debugging features built in.

12. DBMonster

DBMonster is an open-source application to help you tune database structures and table indexes, as well as conduct tests to determine performance under high database load. It’ll help you see how well your database/s will scale by using automated generation of test data. It supports many databases such as MySQL, PostgreSQL, Oracle, MSSQL and (probably) any database that supports the JDBC driver.

13. OctaGate SiteTimer

The OctaGate SiteTimer is a simple utility for determining the time it takes to download everything on a web page. It gives you a visualization of the duration of each state during the download process (initial request, connection, start of download, and end of download).

14. Web Page Analyzer

The Web Page Analyzer is an extremely simple, web-based test to help you gain information on web page performance. It gives you data about the total number of HTTP requests, total page weight, your objects’ sizes, and more. It tries to estimate the download time of your web page on different internet connections and it also enumerates each page object for you. At the end, it provides you with an analysis and recommendation of the web page tested – use your own judgment in interpreting the information.

15. Site-Perf.com

Site-Perf.com is a free web-based service that gives you information about your site’s loading speed. With Site-Perf.com’s tool, you get real-time capturing of data. It can help you spot bottlenecks, find page errors, gather server data, and more - all without having to install an application or register for an account.

More Tools and Related Resources

• Apache JMeter

  a Java-based desktop application for performance testing Apache servers.

• The Grinder

  an open-source load testing framework that intends to make automated tests simpler.

• OpenWebLoad

  yet another excellent open-source load testing tool for web applications.

• “Optimizing Page Load Time”

  an article on improving page load time.

• “What the 80/20 Rule Tells Us about Reducing HTTP Requests”

  a blog post on the YUI blog explaining the precedence of front-end performance for optimal response times.

If you have a favorite web performance tool that wasn’t on the list, share it in the comments. Would also like to hear your experiences, tips, suggestions, and resources you use.

Resources: sixrevisions.com

N-Tier Application Development with .NET

A few articles on n-teir architecture in .Net

Part 1:What is N-Tier Architecture?
Part 2:How to implement the Business Layer
Part 3:How to implement the Data Layer

LLBLGen::About n-tier development
N-Tier Applications and .NET

Part 1:Architecture prototype revised and tested - level 400
Part 2:Architecture prototype revised and tested - level 400