Dreamcatcher

Yesterday I prepared a short video tutorial that shows how to download full length mp3 files from last.fm. You don't need an account on last.fm.
Most tutorials for downloading music from last.fm depend on some way to record the running stream - this is not the case with mget. It will give You the direct download link to the track that You can use with Opera or anything else that You use to download files.

There is a little bit of Opera advocacy smuggled into the tutorial Have Fun!

• English tutorial
  
• Polish tutorial
  

If anyone wonders, this tutorial was created using wink

It's been 5 months since the last release of Movie Get. Defc0n and I are both busy working in real-life but we are proud to present the 1.50 release of Movie Get. The project site is here and You can download Movie Get on Your machine from here.

Here is the changelog for this version:

Fixed support for:

• dailymotion.com ( issue #62 );
  
• gazeta.pl ( issue #62 );
  
• glumbert.com ( issue #62 );
  
• itvp.pl ( issue #62 );
  
• sevenload.com ( issue #62 );
  
• veoh.com ( issue #62 );
  
• patrz.pl ( issue #53 , issue #56 , issue #57 );
  
• smog.pl ( issue #54 );
  

Removed support for (these sites are no longer avaible on the network):

• stage6.com ( issue #61 );
  
• loadup.ru ( issue #63 );
  
• czechtv ( issue #63 );
  

Added support for:

• last.fm (mp3 and video) ( issue #59 );
  

Ruby is no longer required on MS Windows (the installer contains all the required files), thanks to rubyscript2exe. This saves a typical Windows user ~22MB of download.

We are mostly proud of last.fm support. You can download both mp3 and video content with mget from last.fm. But in order to download content You have to register a free account on last.fm and add at least 14 tracks to Your playlist. After that You can give mget url's like http://www.lastfm.pl/music/The+Offspring/_/The+Kids+Aren't+Alright and in return mget will give You back a direct link to full length mp3 files. It may take some time before mget returns the link. If it fails with a cryptic error then Your network probably timedout. Just try again and it should work

A little example to get You started

C:\Users\mulander>mget -sdC "http://www.lastfm.pl/music/The+Offspring/_/The+Kids
+Aren't+Alright"
[?] To use the LastFM module, you need at least 14 tracks on Your playlist!
LastFM decided that in order to view this movie you must identify
LastFM username: YourAccount
LastFM password: YourPassword
http://play.last.fm/user/1b4b32a32ee6e08a08bbc7a6c3e999e5.mp3
--22:28:40--  http://play.last.fm/user/1b4b32a32ee6e08a08bbc7a6c3e999e5.mp3
           => `./LastFM000000.mp3'
Resolving play.last.fm... 87.117.229.109
Connecting to play.last.fm|87.117.229.109|:80... connected.
HTTP request sent, awaiting response... 302
Location: http://s10.last.fm/user/9650693/1b4b32a32ee6e08a08bbc7a6c3e999e5/116/0
004618070/a760648797f04e38f6477388d584973a/1213302521/10.0.0.25/164001545.mp3 [f
ollowing]
--22:28:40--  http://s10.last.fm/user/9650693/1b4b32a32ee6e08a08bbc7a6c3e999e5/1
16/0004618070/a760648797f04e38f6477388d584973a/1213302521/10.0.0.25/164001545.mp
3
           => `./LastFM000000.mp3'
Resolving s10.last.fm... 87.117.229.97
Connecting to s10.last.fm|87.117.229.97|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2á918á608 (2.8M) [audio/mpeg]

100%[====================================>] 2á918á608     16.44K/s    ETA 00:00

22:31:30 (16.78 KB/s) - `./LastFM000000.mp3' saved [2918608/2918608]

You can order a NetBeans Starter Kit DVD directly from the netbeans.org (here) website, the DVD will be sent to You for free (all shipment costs covered by Sun).
The idea is similar to Ubuntu and OpenSolaris shipping option. My copy of the DVD arrived today while I was at work.
This is a very nice option for people with limited or slow bandwidth. It's also nice if You don't like to Google for reading materials.


The Starter Kit DVD contains software distribution files for Windows, Linux, Solaris x86, Solaris SPARC, Mac OS X and the following list of items

• NetBeans IDE 6.1
  (All packs included)
  
• JDK 6 Update 5
  
• GlassFish V2 UR2
  
• Apache Tomcat 6.0.16
  
• NetBeans IDE 6.1 Documentation
  
• Java Platform API Specification
  
• Selected Java Tutorial Trails
  
• "Java Programming with Passion!"
  by Sang Shin
  

How many of You work in a big corporation, dashing out code in a programming language which You don't like? Wouldn't it be great to code a little bit of python or [insert Your favorite programming language here] from time to time?

If You really happen to work in a big company then You already know that this isn't as simple as it sounds. You probably have coding standards and company approved technologies. How can You possibly sneak some code in, avoiding all off those obstacles? Most importantly how to get Your manager to assign time for coding in languages that *You* not the company wants?

First of all, don't charge the revision control with every snippet of code that You happen to have at hand. Try looking around first. Is there a place where Your favorite language could help in the development of Your companies flag product? Every language has it's benefits and is better then the rest at specific tasks.

In my case it all started with a simple script to do some search&replace and file splitting operations on the current code base. Note that this wasn't a task that I made up for myself. I had to ask around and talk to different people to know that this was planned. The need was there, and 150 lines (without comments and blank lines) of Python satisfied it.

The first script You write in the language You were able to choose is really important. You can't mess up at this point. Make the code readable! Even if fitting it all in 70 lines of code less is tempting. Document it. Even if skipping the docs would cut the implementation time in two. Write some simple unit tests for the code if Your company happens to use unit tests in their own products, or do them if You have some spare time. Create a simple usage instruction so people will be able to use the script without consulting every step with You.

Now, You probably think that this is overkill for a throwaway script, but keep in mind that the company paid You money for the time You spent working on it. They certainly don't want to throw it away. And no, making it bigger this way isn't cheating. Remember that someday You or someone else may have to extend the scripts capabilities, the docs and unit tests will come in handy then.

The first script payed off in my case. I was given a second task. Another script to traverse the current source, analyze it and generate some SQL for the database. This again took around 100 lines of Python.

It all went down hill from there. I was asked to code a script that would search hard coded messages in the current code base, judge if the text is intended for a human operator and if so include it in the results. I decided to store the results as XML and present it in the users browser using XSLT. The total for this script was 300 lines of Python.

At this point I started to built a toolkit that I could reuse in future projects. I looked back at the code I wrote before and extracted the parts that seemed to appear more often. I also started to write some classes on my free time, based on the observations I made so far.

I looked at our code base and found a way to automate some tasks by writing scripts that would be hooked into our source code management system. I wrote a document describing the project. Included the estimated time that I would need to implement it and most of all wrote a working prototype on my free time. My project got accepted and is now in queue for implementation.

The reason that it is in queue now is that I got two other Python programming tasks. One to implement a parser for our code base that understands it's structure and can do further analysis of the code, gathering data and presenting it to a human for refactoring purposes. Implementing this script took ~3000 lines of Python (including a GUI in Tk), 18 pages of user documentation, 2 XSLT files for nice output of the results and over 60 unit tests (I realize that it's a small number of tests). A nice side effect was having technical documentation generated by Epydoc. The second task was a simple search script that took ~100 lines of Python and reused an old XSLT file.

I didn't even start writing the project that I suggested and a new one is on the horizon. There is one script used almost daily by every programmer in the company. The script wasn't written by me but it's in Python. I was asked to extend it's functionality which I gladly accepted, as the code is written in a clean, logical and readable way.

To summarize all of the tips I wanted to share:

• Start small, by writing scripts that ease daily tasks
  
• Keep Your code base clean and readable.
  
• Document Your code
  
• Use Your favorite language where it works best. Don't use a hammer when a screwdriver is better.
  

In the beginning You will be the one asking to code some stuff in [insert Your favorite language]. When someone notices that the time invested on Your ideas paid off, then They will ask You to implement their own ideas. The chances are that They will be less strict about the language choice They allow You to make.

I managed to sneak in ~3650 lines of Python code. How many lines did You? And in what programming language?

In the beginning I took every opportunity to introduce a new user to Linux. Soon the number of users started to outgrow my support capabilities, and I had to think about a new approach before I bite more than I can chew. I always believed that simples solutions are mostly the best ones, so here is what I came up with.

I decided to focus on few non tech savvy friends. They all don't need their PC's to do their work. They use it for entertainment, browsing the web, using e-mail, gaming. No photoshop, no deadlines to satisfy etc. I set up a few ground rules to follow.

• Before the installation sit down with your friend and try to learn as much about his computing habbits as you can. Ask what software he uses, how many people have access to the same machine etc.
  
• Choose one distribution or maximum two but they have to be very similar - in my case Linux Mint and Ubuntu
  
• The first installation should always be dual boot. If the user decides he no longer needs Windows, you can always remove it later - it's important that the user still has a way to do things the old ways if something goes wrong or there isn't enough time to find a workaround.
  
• Do the first installation yourself, with your friend watching the process, answer every question he asks and describe the whole thing. Don't be boring, don't make it to technical.
  
• Have a list of as many application alternatives as you can find. Focus on thoose you have the most expirience with.
  
• Teach the user how to solve common problems on their own, but make sure he always can get in touch with you to obtain help.
  
• If you get a support call/msg - be calm, get as much information as you can obtain. Never assume that things got to the point of no return and don't let your users think like that.
  
• After installing the system, let the user explore it. Help only when you are asked for it. Don't flood the user with suggestion for improvments. Let him feel at home and get used to the new system. This is the time whe he should install the software that he needs to get his tasks done. Give him the information he needs to install the software (name, where to find it, how to install it and how to find alternatives on his own) but let him install them himself.
  

I tried this approach already, and I'm quite happy with the results. I have much more time for each user, because I focused only on thoose few. Allowing the user to explore the system on his own, leads to situations when they contact me to anounce what cool software they found or what a fantastic new thing they learned. People guided by hand from the beginning through out the whole process get stressed a lot easier, they start to think that you do it because it is hard to grasp the system, if you give them a free hand they feel better because they know that you believe they can handle the system on their own. Most importantly they know that they can always contact you in case of an emergency. As for now I recieve much less support calls then before. Users that aren't afraid of the system tend to seek answers on their own, and call you only when they have real problems. It worked in case of my little experiment. After some time, you will notice how they get emotionaly attached to the system and this is the moment when this method really pays of.

Both of the users I choose for this experiment became very happy with their systems. Both of them are non tech savvy as stated in the beginning and that is great in this particular situation I will explain why a little bit later. The point for now is that you have a couple of happy Linux users that want to share their happiness with the rest of the world. Now is the point that you should step in and guide them. They are now ready to take your place but are in a much better situation then when you started. Earlier I claimed that it is good that they are not technical users. Imagine this situation, you visit a friend and ask him to try out Linux. He might have heard about it or not, he knows that you are expirienced in computers but he isn't. The most common approach of such user will be avoidance. He might assume that this system is to hard for him on the sole fact that you are using it. Now, look on this scenario from the perspective of our new users. They visit their friends, their friends visit them. Most of their friends are also not into details of computing, they just want to use it. Their friends see them using Linux. They talk about Linux. All of a sudden this penguin doesn't look so dangerous. Your new user suggests that he will help his friend install the system. You are only there for backup. If he asks you to help with the installation do it, but be there as a helper not the tech guy that does all the black magic for them. He has to install the system, just help him if you see some things going the wrong way - otherwise don't interrupt. You are there to make him feel more confident - not to take away what he wanted to do in the first place. In time he will feel confident enough that he will do the installs without you. Another important things is that he is the support for the people he switches. Not you. If his friends call him with a problem he can't solve - then he can always ask you, but never take away his support responsibilities. In time he will switch more users, just make sure that you tell him about the bigger picture. Talk with him and make sure he doesn't take on more than he can handle. If all goes well his users will replicate the whole process switching even more users etc.

Some of you might wonder at this point if all of this works. In my case it did. This "distributed" advocacy did wonders in my case. I started with two users. After a while one of them convinced his brother and the second one his cousin. They both asked me to be present at their first installation, so I was there. Then one of them had their wife switch and that was it for this user, he doesn't have as much time to support more but he still promotes Linux. He even did a presentation for wote on each sork in open office with a nlide that it was created using open software on Ubuntu Linux. The second user didn't stop with his cousin, soon his sister's PC also had Ubuntu Linux installed, and a friend from his school. They both have no problems in supporting their users and I only had a few calls for help. I was not present on the next installations, they handled it themselves. I had some calls during one of the installations but I didn't need to show up to fix things. Now the second phase kicks in, as I was told that the brother of the first user had some friends install Linux but I have no more details yet. All in all things look good. I have less users to support and they mostly handle everything themselves.