Revision keywords:
These matter more if you're working from the command line although similar functionality is built into most GUI clients for places you use them. HEAD is the only one you'll be interested in when sending requests to the repository, and simply is the latest commit. The other three are used when looking at the working copy. BASE is the revision number of the local copy, COMMITTED refers to the last reversion number with a change to that file, and PREV is COMMITTED-1, referring to the version just before that change.
Friday, May 13, 2011
Using SVN Repositories part 1: cleanup and locks
Most of us have, at one point or another, set up an svn repository for a project. Maybe it was a requirement, or was heavily recommended. But we just got by on the most basic stuff available. Commit, update. If we were lucky, we ran into a situation where we had to revert, and on occasion a team might have to deal with merging of a conflict. But what other functionality can SVN offer? And what exactly does that cleanup command do?
Well, to answer the second question, SVN updates to working copies behave similar to a journaled file system. The client will make a private "to-do" list of the actions it's going to take. Then it makes the updates, locking the parts as it's working on them. Finally, it releases the locks as it finishes each part and removes it from the todo list. If something goes wrong, that list is still there, and cleanup just goes through and finishes things, releasing any locks along the way.
Locks: you can lock svn files so that others can't edit it while you're doing so, but they're "soft" locks, very easy to break. Treat them as more of an additional communication measure.
Well, to answer the second question, SVN updates to working copies behave similar to a journaled file system. The client will make a private "to-do" list of the actions it's going to take. Then it makes the updates, locking the parts as it's working on them. Finally, it releases the locks as it finishes each part and removes it from the todo list. If something goes wrong, that list is still there, and cleanup just goes through and finishes things, releasing any locks along the way.
Locks: you can lock svn files so that others can't edit it while you're doing so, but they're "soft" locks, very easy to break. Treat them as more of an additional communication measure.
What makes a good software engineer
I found an article here describing the qualities of a good software engineer. Several of the points are similar to ones we heard in class. Some of the points that resonated with me:
Having a "right way" of doing things, and don't let it slip. Good quality, maintainable code is a result of this, and compromising just because you're short on time will likely end up bad
Be willing to suffer a bit trying to figure things out yourself before going for help. I think the class took this a step further with the whole "chain of command" idea, where you rely on yourself, then a little research, then your peers, then whoever's above you.
Never stop learning. This one kind of applies to all walks of life, but especially with a software engineer. There's always a new language, some new paradigm, a design pattern that makes things easier, more maintainable, or more understandable. We live in a fast-changing field, and it pays to keep up and keep ahead
Share that knowledge. A strong team that you had a hand in making is going to have more value than you alone having that knowledge. Keeping what you know too secret within your team just opens the way to over-competitiveness and backstabbing, neither of which is going to help the team as a whole
Having a "right way" of doing things, and don't let it slip. Good quality, maintainable code is a result of this, and compromising just because you're short on time will likely end up bad
Be willing to suffer a bit trying to figure things out yourself before going for help. I think the class took this a step further with the whole "chain of command" idea, where you rely on yourself, then a little research, then your peers, then whoever's above you.
Never stop learning. This one kind of applies to all walks of life, but especially with a software engineer. There's always a new language, some new paradigm, a design pattern that makes things easier, more maintainable, or more understandable. We live in a fast-changing field, and it pays to keep up and keep ahead
Share that knowledge. A strong team that you had a hand in making is going to have more value than you alone having that knowledge. Keeping what you know too secret within your team just opens the way to over-competitiveness and backstabbing, neither of which is going to help the team as a whole
Project Value Analysis
Cool projects are great, but any project in the professional world needs to have some value. This, as we heard during presentations today, is especially true with potential entrepreneurs. I found a couple of suggested points to keep in mind when considering this in an article here
1. Revenue generation from the new application
2. Cost reductions from the new application or upgrade
3. Indirect revenue generation
4. Increase in exiting user base due to some new features
5. Increase in market share
6. Revenue increase in companion application
It even explains why it might make sense to consider these when you're not directly involved with the selling and such. "Taking the business and value aspects into consideration during development enables you to view the project from the clients perspective. This in itself makes taking decisions regarding certain technical issues easier"
1. Revenue generation from the new application
2. Cost reductions from the new application or upgrade
3. Indirect revenue generation
4. Increase in exiting user base due to some new features
5. Increase in market share
6. Revenue increase in companion application
It even explains why it might make sense to consider these when you're not directly involved with the selling and such. "Taking the business and value aspects into consideration during development enables you to view the project from the clients perspective. This in itself makes taking decisions regarding certain technical issues easier"
Writing good atomic requirements
A good atomic requirement should encompass a few key points.
First, a requirement number. This allows easy tracking
Second, a brief description and what type of requirement it is (functional, aesthetic, etc)
Third, a rationale for implementing it
Fourth, what criteria will be looked at to judge it completed
Fifth, a priority
Sixth, what user story it came from
This allows all the relevant information of a requirement to be read at a glance. Imagine a 3x5 card
First, a requirement number. This allows easy tracking
Second, a brief description and what type of requirement it is (functional, aesthetic, etc)
Third, a rationale for implementing it
Fourth, what criteria will be looked at to judge it completed
Fifth, a priority
Sixth, what user story it came from
This allows all the relevant information of a requirement to be read at a glance. Imagine a 3x5 card
Delegation and adaptors
So you have this code you want to reuse. You can extend the class, inheriting not only what you need, but everything else along with it. In java, this also limits you, as you can only extend one object at a time.
An alternative is to make a class that delegates to the reused code.
An adaptor is a class specifically used in between legacy code with one interface and new code that wants another interface. The adaptor presents the new interface, effectively translating things and allowing the legacy code to exist within the new design.
An alternative is to make a class that delegates to the reused code.
An adaptor is a class specifically used in between legacy code with one interface and new code that wants another interface. The adaptor presents the new interface, effectively translating things and allowing the legacy code to exist within the new design.
What do unit tests and Agile Programming have in common?
Unit tests should be able to be run fast and often. Agile methods emphasize fast iterations. In both cases, the idea is that you find out mistakes quickly. And you will make mistakes.
Subscribe to:
Posts (Atom)