Sometimes you gotta stretch the definition of things...
If you have a new application that needs interprocess communications, but you don't want to build the whole infrastructure, consider using something like email or instant messaging for IPC. Many modern languages have libraries that support email, so it's not a difficult thing to add, and allows you to take advantage of the entire internet connectivity. You also can use it for communications back to developers, when significant errors occur.
Instant messaging can be used as well, but there are fewer libraries built-in to langauges. It's faster and more connection-oriented, but less well-supported across the networks. You will have a variety of IM protocols to choose from, and a plethora of servers to run, should you choose to run a private server.
Another useful hack for developers is to use Gmail as a poor-man's FTP utility. Since you have over 2.5GB of space on an account, it will be large enough for most any transfer. You probably will want to encrypt your files, however, to preserve security. This will pose a slight problem, as Google blocks encrypted archives. Never fear, because you can use something like uuencode to convert an encrypted file into pure ASCII. After downloading the file, uudecode will convert it back into its original binary form.
Andrew Tannenbaum has been quoted as saying "Never underestimate the bandwidth of a station wagon full of tapes shurtling down the highway". As network speeds have increased, so has portable storage density, so the saying is probably as true now as it was then, with only the vehicle and media changing (I'd probably reference a minivan full of USB thumb drives, personally). Sometimes the brute force approach is the best combination of simplicity and utility. If you need to be able to do a rapid upgrade with the ability to just as rapidly return to the initial setup, look into the cost of simply making a complete copy of the machine in the new configuration, and perform the switch by swapping the network connections.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
Saturday, February 18, 2006
Friday, February 17, 2006
How Not To Be Seen
It's relatively rare these days to be part of a team that is just forming. Most of us start a new job with a bunch of existing developers already working on the product. So there is a period of adjustment as you learn the new team's process and culture.
One of the worst things to do during this time is to start commenting on the team's practices in a critcal manner, even if they are suboptimal. This will not endear you to your new colleagues.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
One of the worst things to do during this time is to start commenting on the team's practices in a critcal manner, even if they are suboptimal. This will not endear you to your new colleagues.
- Don't assume that they are not reading current journals. If they are not taking advantage of the latest technology, it may not be because they haven't heard of it.
- Don't act surprised if they don't have all of the Best Practices implemented. Company politics, inertia, and scheduling may prevent them from implementing them
- Don't try to impose your favorite practice. You will appear arrogant. No matter how good an idea it is, you will piss people off.
- If you really wish to change, build support from within. No group welcomes an outsider trying to change things by fiat.
- Don't go running to the manager to get things done without first. It looks to coworkers like you can't support your idea, and want to short-circuit the team's evaluation of the idea.
- Never talk about how great the process was at your last job. The team has had to work under this company's system, and they are probably making the best of it here.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
Monday, February 13, 2006
Hints for new programmers - someone else's view
I was poking about today and happend across this article about what advice to give a new programmer. Overall, I agree with it, except for the parts about a coding standard, Singletons, and comments.
Singletons are more than just global variables. Even if you code them to just be wrappers around global variables, you've gained some encapsulation, and that will help you when you need to track changes to something global - you put a trace statement into the set function for the value, and you'll see where it's getting changed.
A single coding standard is important - the article shows a small function with 2 different styles and states that it's easy to work out the code flow and intent. Well, sure it is, when you've got only 5 lines of code. Where a coding standard shines is in functions that are longer, with more complex interactions. I had the misfortune to be looking at some code recently that as far as I can tell had been developed by at least 3 different people, each with a different indentation setting and brace style. I found differences in one function (about 30 lines) in intertwined sections of the code. Following the logic was difficult because I had to keep going back to the start of each clause to see if I was exiting a layer. If you can't get your development team to agree on a standard, enforce one with an automated tool - you will be thankful later.
And finally, comments. The article does recommend using comments for the WHY and not the WHAT, and rightly ridicules commenting each change in the top of the file, but if you don't comment on the why of each non-obvoius path in the code, the developers that come after will miss it.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
Singletons are more than just global variables. Even if you code them to just be wrappers around global variables, you've gained some encapsulation, and that will help you when you need to track changes to something global - you put a trace statement into the set function for the value, and you'll see where it's getting changed.
A single coding standard is important - the article shows a small function with 2 different styles and states that it's easy to work out the code flow and intent. Well, sure it is, when you've got only 5 lines of code. Where a coding standard shines is in functions that are longer, with more complex interactions. I had the misfortune to be looking at some code recently that as far as I can tell had been developed by at least 3 different people, each with a different indentation setting and brace style. I found differences in one function (about 30 lines) in intertwined sections of the code. Following the logic was difficult because I had to keep going back to the start of each clause to see if I was exiting a layer. If you can't get your development team to agree on a standard, enforce one with an automated tool - you will be thankful later.
And finally, comments. The article does recommend using comments for the WHY and not the WHAT, and rightly ridicules commenting each change in the top of the file, but if you don't comment on the why of each non-obvoius path in the code, the developers that come after will miss it.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
Sunday, February 12, 2006
Developer Tip: Yet Another API point
Just a quickie -
When you write the functions for an interprocess API, don't put the work part of the API in the catching functions. If you put the guts of the work into the catching function, changes to the API directly affect the work part. Instead, if you have a small dispatching function as the catcher, and delegate the work to another function, you can reuse that function for later version fo the API functions, without needing to completely rewrite the work function.
You will need to make the work function fit the newer version of the API, and the older version catcher function will need to be modified to send the new parameters to the work function, but that is relatively minor work compared to a total clone, or complete rewrite.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
When you write the functions for an interprocess API, don't put the work part of the API in the catching functions. If you put the guts of the work into the catching function, changes to the API directly affect the work part. Instead, if you have a small dispatching function as the catcher, and delegate the work to another function, you can reuse that function for later version fo the API functions, without needing to completely rewrite the work function.
You will need to make the work function fit the newer version of the API, and the older version catcher function will need to be modified to send the new parameters to the work function, but that is relatively minor work compared to a total clone, or complete rewrite.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
Subscribe to:
Posts (Atom)