Buy Viagra Soft

Version control is a critical part of any successful development team. You might think that your project is small or that no one else will be joining the team so version control is not needed. This is dangerous thinking because the future is always surprising. Your assumptions may be wrong but even if they are not, a good version control system will still save you countless hours of rework and frustration. Note that I said a good system, many teams out in the wild are still wasting time with Microsoft’s visual source safe (VSS) every day. Historically CVS has been the system of choice for those wanting something reliable with a low cost. CVS does a much better job than VSS in almost every way, (cost, reliability, features). If you have ever tried to use VSS remotely or had multiple developers changing the same files you know what I mean. CVS however has some limitations and Subversion has started to replace many installations. Subversion was designed to be a replacement for CVS and fixed some of the warts that it had. I highly recommend Subversion and I will be documenting my reasons here along with some good practices. Before I get started you should visit The Free Online Book which has been one of the most commonly referenced to documentation on the topic. Subversion gets much of its power from simplicity. As you would expect the repository can contain any number of folders that contain other folders or files. These folders can be set up to represent almost any structure but the convention has been to set up 3 main folders for any given project; Trunk, Branches and Tags. The Subversion(SVN) books to date have taken a different perspective on how these 3 folders should be used because none of this has been well defined by the SVN development team or source documents. Why should it be? How you use SVN depends greatly on what you expect to get out of it. The simple design of the product allows for many innovations helping us improve how developers work together. Based on my experiences, I believe this is the best way to use SVN for a project.

• Trunk Keep the latest working copy in trunk unless this is a new project, in which case the folder is empty until your first commit. The code in trunk will always successfully compile and pass the automated unit tests. Developers, testers, management or anyone else who needs a reliable working copy can always go to trunk.
• Branches All development work requiring any significant time will be done in folders under the branches folder. The developers are free to commit their work daily or more frequently and even rollback without impacting the rest of the team. This frees them up to focus on the software instead of loosing any previous work. Once the new changes are done and tested the branch will be merged into the trunk. After the merged trunk is tested and those changes committed the specific work folder under branches can be deleted.
• Tags When significant milestones or external releases are achieved the trunk is copied to a specific folder under the tags folder. If legacy maintenance becomes necessary the tagged folder can be branched to complete the work. This will be critical if different versions of the project must be supported simultaneously.

PROJECT NAME |-trunk | |-SRC AND OTHER DEVELOPMENT FOLDERS | |-tags | |-myfirstrelease | | |-SRC AND OTHER DEVELOPMENT FOLDERS | | | |-ver2.0 | | |-SRC AND OTHER DEVELOPMENT FOLDERS | |-branches | |-feature32 | | |-SRC AND OTHER DEVELOPMENT FOLDERS | | | |-issue20 | | |-SRC AND OTHER DEVELOPMENT FOLDERS Cool features of Subversion in no particular order:

• Backups are easy. If all the users are logged out svnadmin dump can be used for a reliable backup. If there are users who will not leave then svnadmin hotcopy can be used for a quick backup.
• Nothing is ever deleted. Even delete gets a revision number and you can always fetch old revisions even if the folder is no longer part of the current revision.
• Folder renames. Folders can be renamed while retaining their history.
• Atomic commits. When committing a group of changes to the repository they will all be done at once or none at all. This helps prevents anyone from getting a partial commit or broken copy of the code base.
• Fast light weight copy for branches Branches are light weight copies so they are cheap and made quickly. When you start making changes to the new branch only the difference from the master copy need to be kept saving time and hardrive space.
• Rollback is easy The merge command can be used to quickly rollback your working folder.

Other reference material: Setup Subversion for Java development with Eclipse. More links from Google

Adding Google Suggest to firefox has saved me time by helping me quickly find more relevant results by asking the right questions. Suggest gives me the the related words most commonly searched for with the keywords I have already entered. This helps greatly because the human brain is much better at recognition than it is recall. eg. It’s quicker for me to pick the right words related to what I want than for me to remember or guess what other people are using. Step 1 - get the plugin. Straight from google! Step 2 - increase your search box width. Nice if you like to see more than 2 words at a time.

I found a great little Python script that subscribes to your favorite rss feeds and sends them to you via email. I have it running on a server at home, subscribed to a short list of ‘important’ blogs. It was originally for Linux but ported to windows. So far its working well. rss2email for windows There are instructions on the site below the 3 py downloads. Before you start it up be sure to edit the rss2email.py file and change the SMTP_SERVER and related variables.

There is a great article on Sequence Diagrams that I regularly reference over on IBMs site. Sequence diagrams are easy to understand and use but with the addition of frames from UML2 they sometimes become much harder to read. Previously an architect would be forced to use multiple sequence diagrams in order to fully document all the alternate paths and error conditions for a given system. With frames, many of these alternate paths can be shown in the same diagram but this often adds enough “visual noise” that the diagrams may become hard to understand and therefore less useful. Don’t go overboard in your documentation, this will help eliminate really busy diagrams. Keep in mind these 2 points.

• Who is your audience? What level of technical understanding to they posses? How much time will they stay focused on what you have to say?
• What is your goal? What are the most important things that must be communicated to your audience? Are there any details that distract the reader from the main point which can be removed or summarized?

Clear diagrams and documentation are always well worth the extra effort. Bad documentation will end up stealing your time in the long run as you continue to answer the same questions over and over. Good documentation will boost your productivity because they will be used by those with questions who would have taken more of your time.

Often I find myself involved in projects that are overwhelming. This is common if you have many interests and you are ambitious. One must always keep in mind that large projects can be broken down into smaller steps. Don’t think about all the work or trying to get everything done. It’s better to have a realistic understanding of how many hours you are free to work on your project today and what goals you can set for the day. Set goals that have an above average chance of success. At the end of the day you should measure your progress against your deadlines and make your first attempt to bound the goals for tomorrow. Don’t get stressed out about any upcoming deadlines. If it becomes clear that you need more time then you can honestly explain the situation to management. You may need to rework the rest of your schedule to make longer work days but you can take pride in meeting your daily goals and you will no longer be paralyzed like a deer in headlights. Just live your life one day at a time, thats all anyone can ask.