Before I post these, what do you think would be the fastest of these browsers:
-IE 6, 7, 8
-Firefox 3
-Chrome
-Opera
Now check out the actual results.
The commentators make some good points. FF isn't an internet "suite", and many people download addons on to it that make it slower and eat more memory. Chrome is fast, but it has very few bells and whistles.
Internet Explorer has no excuse, of course.
Saturday, September 26, 2009
Wednesday, September 9, 2009
[INDUSTRY] Visual Source Safe is...
...neither visually appealing nor a safe repository for source code. Ha ha, what a lame play on words.
While we're on the subject of source control, I thought I'd bring up Visual Source Safe (VSS), which many companies out there still use.
VSS is a joke. I've used it. A few quick reasons why VSS is a terrible source control system:
This article that does a better job summarizing the argument against VSS than I ever will.
While we're on the subject of source control, I thought I'd bring up Visual Source Safe (VSS), which many companies out there still use.
VSS is a joke. I've used it. A few quick reasons why VSS is a terrible source control system:
- It costs money. That in and of itself should dissuade you, when there are better implementations out there that are free. It'd be like paying for Windows- oh wait. I mean, it'd be like paying for Internet Explorer. Six.
- You can permanently delete files. How exactly is this different from a normal file system, again?
- You can't make branches.
- "User-unfriendly" does not even begin to describe it. It could easily be used as an example of bad usability design, sort of like Microsoft Word's "Clippy". Some (mostly fabricated) quotes by the infamous character, and a quick overview of the problems with it. I mean, the thing was parodied on the Simpsons. Multiple times.
This article that does a better job summarizing the argument against VSS than I ever will.
[CODE] SVN emails and an ethical struggle
One of the things I really loved about my time at Citi was the SVN emails that were sent out whenever a commit was made. No, the awesome people and the incredible amount I learned were secondary to that. These emails were NEAT. :)
Basically, whenever you made a commit to the repository, an email would be sent out with your changes and commit message (i.e. "bug fix to prevent server from crashing") formatted nicely in HTML. Also, it would go to the correct team based on regular expressions. For example, any file path that contained "connectivity" would go to the Connectivity team.
I took a look at the code and actually had to modify it a few times while I was there. It really wasn't that complicated. At my new job, I tried to duplicate the same functionality.
It's been much, much, much more difficult. Any guess why? A W__dows environment vs. our Unix (Solaris) server. Fill in the blanks.
A short list of the problems I've encountered:
As for the text manipulation stuff, Windows' built regular expression search/replace functionality is laughable. My batch file basically just calls a java file that does all the work for me in a very verbose way (Java is quite frustrating at times when you're trying to do something simple).
I wish I could have done it in a scripting language (hello, perl? Or I could get off my lazy butt and learn Python...) but I wasn't sure those were installed on the server, and it'd be an administrative hassle to get them to do so.
After clearing all those obstacles, I'm nearly done with a product that looks even better than the old version. I have nifty additional features like autosizing the divs containing the diffs to be a certain size (if it's a small number of lines, it expands so you can see it without scrolling) and I alternate the text color of consecutive diffs.
For example...
Changed paths:
A /test/myFile1.txt
M /test/myFile2.txt
D /test/myFile3.txt
Exact diffs:
Index: /test/myFile1.txt
+hello world!
Index: /test/myFile2.txt
-hello world!
+goodbye world!
Index: /test/myFile3.txt
-foobar
It looks much cooler than that, but sadly I can't really email myself a copy of it. Which leads me into the second part of this post:
What do you do when you develop a really cool tool that you feel other developers out there could benefit from, but it was made on company time?
After I get my work jar-ed up and documented, I think this could be really neat for anybody out there who wants SVN email functionality on a Windows machine. Literally all you'll need to do is extract the jar and provide the path to your local java installation.
However, this was built on company time, and standard language in any contract is that any work you do while under company time is strictly the property of the company. Even if I build it separately on my home machine outside of work a case could be made that it's basically just copying it from work.
This is unfortunate, because it's such a handy little piece of software (well, in my mind anyway, but then again I built it so I'm biased) and has no real "cash value" since it's so small that nobody would want to buy it. It'd be like trying to sell a specialized text editor. It'd be nice to have, but there are so many other similar implementations that you couldn't charge a penny for it.
There's nothing I can really do about this right now (and don't have the energy to try anyway) but it's something that I'd like to explore in the future. It also raises a point that constantly nags at me. What if I build an awesome tool that doesn't have an equivalent out on the web, but the company restricts its distribution (even if it's not part of the application itself)? I'm not arguing the legality of this, so much as lamenting how many pieces of great software are being held back from public consumption even if they're not turning a profit.
Basically, whenever you made a commit to the repository, an email would be sent out with your changes and commit message (i.e. "bug fix to prevent server from crashing") formatted nicely in HTML. Also, it would go to the correct team based on regular expressions. For example, any file path that contained "connectivity" would go to the Connectivity team.
I took a look at the code and actually had to modify it a few times while I was there. It really wasn't that complicated. At my new job, I tried to duplicate the same functionality.
It's been much, much, much more difficult. Any guess why? A W__dows environment vs. our Unix (Solaris) server. Fill in the blanks.
A short list of the problems I've encountered:
- I'm just not as familiar with the Windows batch file language (is there even a formal name for this?) as I am with Unix. I don't blame Windows for this per se, but keep reading.
- The Windows syntax is terrible. I mean seriously, it's archaic. It's just plain ugly. "REM" on every line for comments? It looks like freaking Basic.
- The general structure of the language practically enforces a single minded procedural approach. Now, if you're trying to rig up something really complicated in a bash script you're probably doing something wrong already, but I have one word that forever invalidates any argument used to defend the language: You are forced to use "labels" for any conditional statements.
- The fact that the Windows file system accepts spaces in file names is absurd.
- Why isn't there a built in email sender? Writing a barebones SMTP client program is a trivial task you could give to a college freshman.
- I struggled with how to redirect the standard error stream to standard out (useful to checking if javac and java worked) until I found this.
As for the text manipulation stuff, Windows' built regular expression search/replace functionality is laughable. My batch file basically just calls a java file that does all the work for me in a very verbose way (Java is quite frustrating at times when you're trying to do something simple).
I wish I could have done it in a scripting language (hello, perl? Or I could get off my lazy butt and learn Python...) but I wasn't sure those were installed on the server, and it'd be an administrative hassle to get them to do so.
After clearing all those obstacles, I'm nearly done with a product that looks even better than the old version. I have nifty additional features like autosizing the divs containing the diffs to be a certain size (if it's a small number of lines, it expands so you can see it without scrolling) and I alternate the text color of consecutive diffs.
For example...
Changed paths:
A /test/myFile1.txt
M /test/myFile2.txt
D /test/myFile3.txt
Exact diffs:
Index: /test/myFile1.txt
+hello world!
Index: /test/myFile2.txt
-hello world!
+goodbye world!
Index: /test/myFile3.txt
-foobar
It looks much cooler than that, but sadly I can't really email myself a copy of it. Which leads me into the second part of this post:
What do you do when you develop a really cool tool that you feel other developers out there could benefit from, but it was made on company time?
After I get my work jar-ed up and documented, I think this could be really neat for anybody out there who wants SVN email functionality on a Windows machine. Literally all you'll need to do is extract the jar and provide the path to your local java installation.
However, this was built on company time, and standard language in any contract is that any work you do while under company time is strictly the property of the company. Even if I build it separately on my home machine outside of work a case could be made that it's basically just copying it from work.
This is unfortunate, because it's such a handy little piece of software (well, in my mind anyway, but then again I built it so I'm biased) and has no real "cash value" since it's so small that nobody would want to buy it. It'd be like trying to sell a specialized text editor. It'd be nice to have, but there are so many other similar implementations that you couldn't charge a penny for it.
There's nothing I can really do about this right now (and don't have the energy to try anyway) but it's something that I'd like to explore in the future. It also raises a point that constantly nags at me. What if I build an awesome tool that doesn't have an equivalent out on the web, but the company restricts its distribution (even if it's not part of the application itself)? I'm not arguing the legality of this, so much as lamenting how many pieces of great software are being held back from public consumption even if they're not turning a profit.
Subscribe to:
Posts (Atom)
Posts
