How to save that flash file you really like

I don't know about the rest of you, but every once in a while, I come across either some flash animation or a flash video/movie that I would really like to download and archive. This way, I can show it to others and share the wealth.

Well, one thing that I always hate is not knowing how to do something that should not be that trivial. One of those things that I had resolved earlier on was how to save a flash file to your hard drive from a website. Believe it or not, its really not that difficult.

NOTE: I am only going to show you how to do this in Firefox as I refuse to fire up that crap program called IE. If you want to know how to do it in there, then you figure it out. I don't use it and I am not going to use it even just to find this out.

That said, the first think you should do is to load the page containing the flash animation that you wish to download. Once you have that done, you now have two choices of how to do this, which I will explain here.

The less geeky/nerdy way:

Once the page is loaded, in your Firefox menu bar, go to "Tools -> File Info". This will bring up a box with a few tabs. One of the tabs is "Media". Click on it. You will see anywhere from one to a bunch of files listed in the Address section of the Media tab. What you want to do is scan through and click on the ".swf" file that you are wanting. Then, once you have done that, simply click on the "Save as" button and select a place to save it on your computer and click "Save".

Believe it or not, thats it.

The more geeky/nerdy/power user way:

Again, once the page is loaded, you want to open a new tab (Ctrl-T for those not in the know). Then, in that tab type the following in the URL bar: about:cache?device=disk

This will bring up a list of EVERYTHING that is in the Firefox cache on your computer. Simply browse it for the file you want. It will have the path to the website it is hosted on. All you have to do is right click and click on "Save as" and save the file wherever you want on your computer.

Again, it is that easy.

So, the next time someone asks about saving flash files, you can prod them in the right direction on how to do it.

The New Printer

The wife told me the other day that she wants a printer here in our "temporary" computer room that used to be a full fledged dining room. (this because my two kids have their own rooms and I am in the middle of creating a home office in my basement that I haven't had a second to touch in about a year. **UGH***) Anyway, going on what she wanted, which was a printer that could print relatively quickly and print well I began to asses what we had in "storage". I have a Canon photo printer. Sure, its capable of printing text, but it is MUCH better at photo's, I must say. The only other printer that I have is a HP Laserjet 1100 which needs a new roller assembly since the present one likes to take in every sheet of paper fed into it all at once. So, you cannot put more than one sheet into it at any given time. This is quite an annoyance when you want to do some heavier printing.

So, I remembered the Sunday ads and that Best"Try" had an HP Laserjet on sale for $99 that printed 15 ppm and was relatively small. So, last night we went to look at it. Sure it was quaint, and I was about to see if they had any in stock when the wife says, "Hey, check this one out, its even a copier." Well, far be it for me to not look at another model. It was a laser printer, copier and color scanner all in one. It was nice and it was a "Brother".

We tested it and it seemed to work great, printing 20 ppm. So, we talked and decided to go with it. Sure, it was double the other one in price, but we could now use it to print out copies of stuff from kids books for the kids to write and color on without destroying the original. Plus, printing was quicker and a breeze.

Well, got it home and last night I hooked it up and were printing in only a few minutes. Gosh I just love new toys. Now I have to hook my Linux laptop up to it and see if I can get it printing.

New Status: Moderator

This is AWESOME!!! Not only is today my birthday, but I was given an unexpected present today.

I have been actively posting and participating in the Perl forum on thescripts.com since about May of this year. I have only posted one or two questions myself, but spend 95+% of my time on their answering others questions as some of them challenge me to research and learn before answering.

Well, I made a bid to the main Moderator for the Perl forum about a week and a half ago to join him in the duties. Well, he put me in for it the other day and this morning I was delighted to find that I had been awarded the honor.

This is GREAT!! I have since been cleaning up posts, moved one posting, and just all around having a blast with my new found moderator status. No, I am in no way abusing it, but I am trying to keep up on all the goings on so as to keep the forum running as smooth as possible.

Happy Birthday to ME!!!

Opinions, opinions

We have all seen the postings on almost every single forum that is out there. You know what I am speaking of, those postings that read, "What is the best IDE for BLAH language?". If you have read any of the tirades.....er.....responses to those questions, then you are fully aware that it is a "my opinion is better than your opinion" atmosphere.

You may get a couple of responses in the beginning, where people are telling you what IDE they use, the pros, the cons, and why they think it is so wonderful, but then it starts. You get this multitude of fascist dictator types that absolutely insist that "there is no better IDE than (input editor here) and that all other editors are crap in comparison!". You even have the old school folks, some of whom can remember creating punch cards, who believe that command line editors or vi are the best editors.

If you are one of those that is getting ready to ask that time-(de)tested question of "Which IDE is better for ...?", then just DON'T!

Here is what I believe, and no, I am not going to go and follow the masses, preaching what I think is the best editor. Instead I am going to sum it up with this..... try them all. Download and install a number of editors. Play with them, write code with them, debug with them, get to know them. While you are doing this, take notes on what you like and dislike about each one. Then, when you are done, compare all of your notes. You have to not only look at the notes, but you have to think to yourself, "will I still like this editor in a 6 months? a year? " The answer may very well be, I don't know.

I am old-school unix. I believe that the command line rules and vi is the best day-to-day editor. All of the coding that I have learned has been by hand. I prefer not to learn with a fancy, shmancy do-it-all-for-you editor as I won't learn anything. I like learning a new language in an editor like vi because I get to debug my code by hand and not rely on a program to tell me what is wrong. This allows me to assess the errors and get my coding (by hand) down to a science. After I am more than comfortable, then I migrate to a more comfortable editor that will save me time.

While vi will always have a place in my heart and my editing world (being the first editor I used on Unix), I must say that I have leaned toward Active State's Komodo for my day to day coding in Perl ( and other misc languages, including HTML). Yes, some will tell you it is a beast and clunky slow. Personally, it takes a minute to start up, but after that, I don't have any issues. I don't have this insatiable need to have my editor at my fingertips within a nanosecond of clicking on the link to launch it. I am patient enough that I can wait the 30 or so seconds that it takes to launch. I use it because I like its syntax highlighting, code sense (hints, kind of like Micro$oft's Intellisense), and overall comfortable feel.

That my friends, is what I think the key is..... comfort! You have to pick an editor that you like and not listen to the skewed views of the mass critics out there.

In a posting to the Boston Linux User's group, Uri Gutman wrote, "so my main point is that coders need to be smarter about their analysis, architecture and design and less caught up in tools like IDE's and syntax highlighting. you can have the greatest IDE in the world and
still come up with crappy code and solutions. whereas a good software design can be written and debugged with any set of tools."

That is one of the best statements that I have read on the subject and it is something that I have believed in for some time. If you aren't able to write good code and be able to debug it thoughtfully, then no editor in the world is really going to help you!

Happy coding!

Things that I learned yesterday

If there is one thing about being a geek that keeps me going every day, is that saying, "You learn something new every day!". Why? Because it is so true. Being a Perl developer has me writing more code than I can keep up with, and I love it. But the best part is, through all of the coding that I am doing, I seem to learn a minimum of one new thing with each program I produce. Now, "1 new thing" seem pretty low, and don't worry, it is as lately it has been a few new things each time, but learning 1 new thing every day keeps the mind in good shape.

For instance, I was working on a script last week that took a file and parsed out of it a string that was ocourring ( that should not have been there). Well, my script removed said offending lines to another file for "safe keeping", while outputting the good lines to their own file. To make sure that everything worked correctly, I had to balance the new file to ensure that ONLY the offending lines were removed and all other lines ended up in the new file.

So, I delved into the File::Util module, which has a function called line_count() in it, which takes a file as input and outputs the number of lines in the file. What I discovered was that the function was working fine with the first file processed (the original file), but on each subsequent file ( the offending lines file and the new outputted file), the counts were totally off, even so much as the offending lines file's count being zero (0).

So, I emailed the developer who produced the module to get his advice and see if there was an issue with the module. After he did his typical tests and did not discover anything wrong, he came back to ask me to ensure a couple of things:

1. That I ran the close() function on each file handle before actually acting upon the file that each file handle was referencing. Well, this was definitely an issue. I had the close routines after everything was said and done. So, I migrated them to close the file handle(s) before doing the line count.

2. He asked me to turn off buffering for I/O. I was a little new to that and asked him to explain further. He said that all I had to do was to set the variable "$|" to any true value:

ie: $| = 1;
$|++;

This would tell Perl that, instead of storing date in memory, that the data going to file handles would go directly to the file handles and not get stored in memory. This not only ensures that all data is written to the file handle(s) as it should be, but also has the added benefit of clearing up any memory usage from the stored information. Also, one other note, you need to set this variable at the beginning of your script so that everything in the script is effected.

So, after modifying the auto flush variable and closing all file handles, the function seemed to work just fine and outputs everything perfectly.

Many, many thanks to Tommy Butler, the author of the File::Util module on CPAN. Without his help, I would probably still be scratching my head over the issue. Now though, I have a bit more knowledge and experience with which to draw upon with my next project.

Checking for duplicates

If there is one thing that I love about Perl, it is that there is always something new to learn. In my case, I like it to be a few things every day, but that is just me.

In my last post, I mentioned about one liners and that I was working with some code that was rather puzzling to figure out. Well, I figured it out and with the help of Learning Perl, 3rd Edition. I have said it many times before and I will say it again. As much as the Camel book is famed as the "Bible of Perl", I tend to keep the Learning Perl book much closer to my keyboard.

There one liner that I was working on figuring out was as follows:

perl -e '$count=0; while (<>) {if (! ($var{$_}++)) {print $_; $count++;}} warn "\n\nRead $. lines.\nTook union and removed duplicates, yielding $count lines.\n"' ./file1 ./file2.txt > ./combined.txt

This code is supposed to take in the two files (file1 and file2) and combine them into one file (combined.txt), all the while, removing any duplicate entries. What puzzled me was HOW IS IT DOING IT? Yes, if you are wondering, it does work. Any Perl guru's out there are already nodding their heads as they probably already know how.

The magic of this code is in the "$var{$_}++". What happens is this, the code takes in the first file and reads it line by line. It then takes each line in turn and creates a key in the hash with it, but it is UNDEF as there is no value assigned. This ends up being a true test. The next line is read in and again it creates a hash key with the line as the key, only this time, if the key already exists, then the test is false as it is already existing and undef, so, the line will not be added to the output file. Its a little confusing, I know, but it works and it is how it was designed to work. Personally, its a great, short system for removing duplicates.

If you still have questions, I recommend you look at the example on page 153 of Learning Perl, 3rd Edition. Yes, I know they are up to 4th Edition, but I have my 3rd edition copy with me at the moment.

Happy Coding!!

Bring on the one liners!

I have been playing with Perl for a couple of years, off and on, not really that intensely. About 6 months ago I really picked up the pace when my last job released its online training courses. I ended up taking the 3 main Perl courses and learned A LOT, all at the companies expense. Almost 2 months ago I landed the job I am in now, as a Perl Developer, and watch as my learning curve took a sharp incline towards the ceiling. I love it when it does that and I really into what I have to learn.

Since getting this job, I have written a couple of scripts for work here that are a few hundred lines long and others that are only a couple hundred lines in length. Not too shabby and they work great.

Recently though (starting last week), I have been working on a Production issue. I did a fix for the issue but have since then been learning how the scripts work. The project is mainly shell scripts, but one of the scripts that is called is a ".sh" file that only contains... yup, you guessed it... a Perl one liner. This one liner is supposed to compare two files and return the lines that aren't duplicates.

Well, in my examination, I will be darned if I can find any where that the one liner is actually doing a comparison. To me, it looks like the script just simply outputs the first file and then appends the second file.

Anywho, that issue aside, during the whole research that I have been doing, I have had the opportunity to really delve into how to do one liners in Perl. It is really rather interesting. Granted, its not my favorite way to code Perl, but for the quick dirty job that takes seconds, it is definitely the way to go.

Heads up --> Opinion Ahead

A buddy from work and I were talking this morning regarding a project that they are wanting to build. He came right out and asked me about Perl's capabilities. I guess that the project that they have to build would be for system management and notifications to distribution lists. It would be databased and they would like a gui for it as well.

"Ok", I said, so what is the issue? I guess that one of his colleagues make the comment that Perl just isn't the way to go for such an application. And I quote: "The database interface is "eh" and the graphical capabilities are not that good either. Perl is really only good for text modifications."

I somewhat choked. Sure, text is what Perl was designed for, but to make a statement so completely confounded without first seeing what has changed with the language is just lame!

It seems that this guy hadn't touched ANY Perl in well over 10 years. Ok, 'nuff said. That means that:

#1. He really hasn't seen Perl lately
#2. He really hasn't seen Perl lately
#3. Perl 10+ years ago and Perl today are two completely different beasts.

Yes, I know #1 and #2 are the same, that was completely on purpose. I listened to the list of requirements for the application and they sound totally feasible for Perl. I cannot divulge them here as it is work related ( I am sure you understand), but believe me, Perl wouldn't have many, if any, issues. Granted, the coding would be a little intense, haveing to use TK, DBI and other assorted modules, but aside from that, it sounds like it would be a sweet application.

The big plus for Perl is that it is a language approved and used inside the organization, so no having to get approval for it. That should make them lean in the right direction.

An Enigma machine on eBay....Oh My!

If you are a cryptography buff or even an aficionado, then I can imagine that your eyebrow raised at the mention of one of these beauties actually being auctioned off.

It seems that someone in Italy is trying to cash in on a bit of history by offering one of these machines to the public. If this turns out to be a true Enigma machine, then this is an incredible find. I can only imagine how lucky the winning bidder will be feeling.

Here is the link: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=270146164488

Granted, in my opinion, something as monumental as the Enigma machine definitely belongs in a museum. My only hope is that, whomever buys it does not keep it locked away, but instead puts it on display for others to see and enjoy.

Of course, if you happen to be a hobby cryptographer, and a handy one at that, then you could always build your own Enigma machine in your workshop. That is definitely an interesting prospect for a project. Hmmm.

Anywho, enjoy the auction. It will be interesting to see how high the bidding goes.

Watch that punctuation

I'll tell you, there is nothing like coding all day and having a really good time doing so, and then, right around mid-afternoon you hit an error that just stops you. You can't figure it out for the life of you.

I am working on a script to automatedly download ALL of CPAN. ( I know.... WHY? Because I want to, that's why. Plus, my laptop isn't always able to get online and when I need a module, if I have it readily available, I can manually install it.)

Basically, the script fetches a copy of the CPAN modules list, and I am then parsing out of the HTML that was returned, the paths to the modules, including the module names. Here is the section of code that was bugging me:


if($line =~ m/\.gz/)
{
@elements = split(/"/, $line);
print PATHS ("$elements[1]\n");
}


I was really wanting this to work ( and the code above does), but when I IM'd Merlyn (Randal Schwartz), he noticed that I was missing a double quote in the print path. Man, after all day coding, I don't blame myself for missing that one. Thanks Merlyn for the second set of eyes on that one!

Once I have the code completed I will post it here.