IT-Tactics

2010-08-05

Screencast recording on Ubuntu 10.04 (and 9.10)

Creating screencasts is not only modern - often a short 2-minute video can be more helpful as a 2 page documentation.

There are two major screencast recording tools available in Ubuntu. That said, I always had troubles with them because I do want sometimes different behaviour or I had issues with the sound. I want to give a very short overview to make it more easy for you to choose the right tool in the right moment and to get the output you want:

gtk-recordmydesktop
+ Very easy interface
+ Works out-of-the-box
- Option to follow mouse available and keeps the mouse always in the center of the frame (I think, this disturbs, when watching the video).
- Cannot export/save as MPEG-4 or AVI or anything else - just .ogv (the open format)
XVidCap
+ Can produce different formats (MPEG-4 is the default, but you can switch to .ogv also)
+ Option to follow mouse available and keeps the frame steady until you move the mouse near the frame border (this way it is more easy for the user to follow the video instructions - you should only make sure that the border of the video is not to near to your primary working area otherwise you get a similar effect as with gtk-recordmydesktop)
- The GUI is slightly less intuitive
- Using the package from the Ubuntu 9.10 or 10.04 repository does not bring you sound support (at least not when trying to create MPEG-4). You have to install the .deb package manually by downloading it from sourceforge (current version is yet 1.1.7 - although the same version seems to be in the repository, that is a different one and does not work - strange, but fact).

I basically use both applications. When I produce local screencasts for end-users that I just save on their local machine for later reference I use gtk-recordmydesktop and just leave it as ogv. That used to work even when Skype + TeamViewer is running and I did the recording remotely. It even recorded my sound coming through Skype! When I want to upload a video to YouTube (or vimeo and others), XVidCap is better because it immediately produces MPEG-4 which fits better for YouTube and similar services (I tried uploading an ogv file from gtk-recordmydesktop to YouTube which failed to replay correctly - indeed it is not mentioned on the appropriate help page).

Especially for the case(s) you prefer gtk-recordmydesktop you might need to convert the created video to the finally desired format. I have seen many ways (reading blog posts and watching screencasts), e.g. using WinFF, VLC Media Player and using Devede. Using Devede was the only one that worked for me (see http://vodpod.com/watch/3665200-converting-your-ogv-files-to-mpeg4-).

In any case you should have the ubuntu-restricted-extras installed (using synaptic package manager or sudo apt-get install ubuntu-restricted-extras) for doing video or audio stuff. I would also install ffmpeg.

I also usually have to put the sound input to a high level otherwise when replayed on several machines (e.g. notebooks or external monitors with poor speaker power), even putting the volume to highest level brought only low level sound.

Final note: It might be necessary to quit Skype (if you have it running) to avoid sound or video juddering.

Related post: Ubuntu 10.04 with docking station.

2010-08-02

Ubuntu 10.04 with docking station

After installing Ubuntu 10.04 I lost proper dual monitor handling for my use case. Basically I want to use my notebook on the road as is and in the office I want to put it into the docking station while having the lid always closed.

Ubuntu 10.04 Lucid Lynx does not handle this properly any more. I found out that also in 9.10 it was probably pure luck for me because I upgraded from 9.04 and had some fixed entries in the xorg.conf.

But anyway, the xorg.conf file is legacy and there is now gdm with xrandr.

I found out that many have the same use case as I have and have problems. Some solutions are particular to NVidia cards, but I have an Intel. Thanks to Nylex in the Linuxquestions-Forum + Ubuntu XOrg documentation, I could find the solution:

I had to put this into the file /etc/gdm/Init/Default before the line starting with /sbin/initctl (why the TV1 is there also look below in update 3):

xrandr | grep "HDMI1 connected "
# 0 is returned on success
if [ $? -eq 0 ]; then
 xrandr --output HDMI1 --mode 1680x1050 --rate 60 --primary --output LVDS1 --off --output TV1 --off --output VGA1 --off --output HDMI2 --off --output DP1 --off --output DP1 --off --output DP2 --off --output DP3 --off
else
 xrandr --current | grep "VGA1 connected "
 if [ $? -eq 0 ]; then
   xrandr --output VGA1 --mode 1680x1050 --rate 60 --primary --output LVDS1 --off --output TV1 --off --output HDMI1 --off --output HDMI2 --off --output DP1 --off --output DP1 --off --output DP2 --off --output DP3 --off
 else
   xrandr --current | grep "TV1 connected "
   if [ $? -eq 0 ]; then
     xrandr --output LVDS1 --mode 1440x900 --rate 60 --primary --output HDMI1 --off --output TV1 --off --output VGA1 --off --output HDMI2 --off --output DP1 --off --output DP1 --off --output DP2 --off --output DP3 --off
   fi
 fi
fi

What it does is: Using xrandr it probes whether an external monitor is attached (whether HDMI or VGA) and if so it turns off the LCD display of the laptop so it is not used. You need to adapt the resolution to fit your needs.

[Update]
I had some cases when (maybe because of timing at startup) it did not work (sometimes it worked after gdm service restart then but not always) added --preferred and --primary to the xrandr call above and I added the script below to System->Preferences->Startup applications:

#!/bin/sh
xrandr --current | grep "HDMI1 connected "
# 0 is returned on success
if [ $? -eq 0 ]; then
 sleep 5s
 xrandr --output HDMI1 --mode 1680x1050 --rate 60 --primary --output LVDS1 --off --output TV1 --off --output VGA1 --off --output HDMI2 --off --output DP1 --off --output DP1 --off --output DP2 --off --output DP3 --off
else
 xrandr --current | grep "VGA1 connected "
 if [ $? -eq 0 ]; then
   sleep 5s
   xrandr --output VGA1 --mode 1680x1050 --rate 60 --primary --output LVDS1 --off --output TV1 --off --output HDMI1 --off --output HDMI2 --off --output DP1 --off --output DP1 --off --output DP2 --off --output DP3 --off
 else
   xrandr --current | grep "TV1 connected "
   if [ $? -eq 0 ]; then
     sleep 5s
     xrandr --output LVDS1 --mode 1440x900 --rate 60 --primary --output HDMI1 --off --output TV1 --off --output VGA1 --off --output HDMI2 --off --output DP1 --off --output DP1 --off --output DP2 --off --output DP3 --off
   fi
 fi
fi

[Update 2]:
It still did not work 100%. Sometimes when I moved the mouse outside the desktop it was gone so I found the laptop monitor being still active (so I could move windows over there and they were gone). I could immediately notice that after login when the workspace icons on the bottom right were displayed with increased width. It helped, explicitly turning of LVDS1 display (the laptop screen) in the script (see appropriate options in the updated script above).
[Rest of update 2 removed because of update 3]

[Update 3]:
It turned out that (occasionally) on boot it recognized another monitor to be active, after first being the LVDS1 it happened also being the TV1 (occassionally) - and I don't know why because I never attached a TV to it. Anyway, I have added the options to turn that off explicitly also to the scripts (see updated gdm default script portion and startup script above).

Apart from that sometimes occassionally a re-evaluation of available displays might be triggered by an application (e.g. opening and closing the laptop lid or manually calling xrandr without parameters or starting arandr or other applications when started the first time). Such a re-evaluation can also occur right after graphical login and then your initial gdm xrandr modifications are forgotten. Therefore it helps having that script at hand (I have it in /opt) and added to the gnome menu under "Other" to run it when necessary on demand.

Apparently also a timing issue remained (I assume that because of the fact, that the startup applications are started in no particular order and all asynchroneously). However, adding a line with "sleep 5s" to the script (only to the additional script and not to the gdm init!!!) helped. I currently use a 10 seconds delay (subject to change maybe) but in your case less might be sufficient or more might be required (for me 5 seconds was not enough to make it work each boot).

For you it might be necessary to switch additional displays explicitely off (as I did with TV1 for example).

Oh, and BTW:
In System->Preferences->Power Management make sure that lid closed action is "Blank Screen". I made a lot of tests with setting to nothing (only possible via gconftool-2) but after all maybe the above setting is the better one.

If in your case the resolution(s) are not set correctly you can do this here in this script also. Use man xrandr or look at https://wiki.ubuntu.com/X/Config/Resolution#Adding%20undetected%20resolutions for more information on the appropriate xrandr commands.
I noticed some flickering and login screen displayed in lower resolution, so I added --mode 1680x1050 to the xrandr call in both cases (in both scripts) which is the resolution of my external monitor.

Honestly, using this script, I feel better than previously on Ubuntu 9.04 or 9.10 where I got it to work by accident after moving around monitors in the config (although in reality they were positioned the other way round). As I found out today, I wasn't either the only one with that experience (see http://ubuntuforums.org/showthread.php?t=1110407) although I am used to be the non-standard user. - With my use case of having the lid closed all the time when in the docking station I am by far not alone as I noticed and some either downgraded to 9.10 because they did not get it to work.

Many, many thanks again to Nylex and the Ubuntu documentation team!

Related links:

2010-07-16

Java applications on the desktop

When it comes to discussions about programming languages on forums and newsgroups, one argument against Java is that there are quite no Java applications for the desktop.

This is definitely not true. I have looked what Java applications I am using (or used a lot in the past), and here is a list:

Yuuguu (Screen Sharing, Web Conferencing, ...)
Freemind (Mind Mapping)
jDiskReport (IMHO the best disk space report tool)
PDF Split and Merge
Yugma (Web conferencing)
jalbum (I have used that very much in the past, but currently don't - but not because it's bad)
LimeWire (Don't use that any more either, but it was good)
SignLiveCC (Digitally sign PDF documents)

And of course, if you are a developer programming in Java, JavaFX, C++, PHP, Python or Scala for example, then you probably use NetBeans or Eclipse - both very popular IDEs (integrated development environments) are written in Java.

There are many, many Java desktop applications out there, look for example at javadesktop.org. You can see the wide area where Java is used on the desktop at geertjans blog here for example or at the NetBeans site here.

One advantage of using Java at the desktop is that you can choose between two core different ways: Swing or SWT. While SWT tries to use the OS specific widgets (to look more like the original OS and be faster), Swing does render everything itself. So SWT is a little bit faster and looks more like OS, but Swing is more flexible (more widgets available) and you can easily use different look and feel / themes (there is also an OS like). In both cases you can develop modern Java desktop applications that look nice and integrated with your OS.

The disadvantage of using Java on the desktop - I will be honest - is startup speed. Once started, SWT and Swing applications behave fast - probably not as a native Gnome application for instance but really - it's fast enough for the user. That startup time is still an issue you will notice mostly, if you write small tools as Java desktop applications. For larger ones it is less annoying because those you don't open and close all the time. If you open the application and tend to keep it open you will have no problem. If you open and close the app frequently then it may become an issue. Same applies for small commandline tools - writing those in Java is maybe not the best option. Anyway, really annoying is only the first start of the first Java application after reboot when the Java runtime is not in the cache yet. NetBeans for example (which is a big Java application) needs 12 seconds on my machine (a year old) when the Java runtime is already in the cache. Freemind is a smaller application and takes only 5 seconds to startup which is acceptable.

If you look also at server-side then ... what should I say .... the world is full of Java applications - too much to cover here (and of course for many websites or web applications you often can't really say from outside what is used behind the scenes).

Related post: Popular Java myths, The future of Java.

2010-07-15

Get reliable local IP address in Java 6

It is strange: I consider myself still being new to Java, but when I search for particular sample code, that should be written thousand times before, I sometimes find only samples that do only half the job or miss important details.
So happened for getting the local IP address(es) of the machine you are running on. I experienced for example performance issues retrieving the IPs when running with a mobile internet stick (point-to-point device).

My example code can be found here: http://pastebin.com/5X073pUc

If you want just one address, that is probably the best fitting then you probable want to use this example: http://pastebin.com/PLAcTXac

Related post: Dynamic method invocation in Java 6.

The small software vendors

Especially these days companies are very careful in choosing their vendors. This certainly also applies for software.

I do get some considerations from customers which I do not really consider being always relevant or true:

"We prefer to buy from large software vendors, because as an international company, we need the availability of support in different countries."
Especially software support can be available all over the world because there is no need to actually sit there. With chat, voice- & video communication plus remote desktop tools support can be done all over the world from a single location.
Further, a large company could have plenty of people sitting in plenty of countries, but this does not mean that all those people have (the same level of) good knowledge of the software. Honestly, those who really know the product, are always the developers and the people who communicate most with them.
"A small software vendor is more likely to fail and go bankrupt and then we have invested in a dead product."
First, present time shows that even a large company can fail (maybe except banks ;-) ).
Second, bankrupty is not the only case leading to a dead product! It happens more often that a product is simply discontinued and this happens for products of bigger vendors also. In bankrupty case, if a product is good there will be other companies taking over the product - especially if money can be made from supporting the product. But if nobody is interested any more in the product your situation is worse.
Third, if you ensure that you have access to the source code (even if only in bankrupt case - which would be sufficient and cheaper in most cases), you always can hire people working on the product implementing the features YOU need (this is a big advantage of Open Source).
"At small software vendors the deep know-how is bound to a few people only which also means a higher risk for the customer."
Nowadays companies do not invest in having a lot of backup resources. This also affects developers. And I have experienced dependency on a few people also at big companies. Just because the company is bigger does not necessarily mean they have more smart people there working on the same stuff. It is more important that the team is continuously motivated and people like to work for the company employing them. A stable and motivated team at the vendor is the key for lasting long-term support of your product.

And last but not least let's not forget about a few advantages of choosing smaller vendors:

Usually more flexible organization.
Better and more direct contact with tech people.
Cheaper - big companies often have a big head of administration and more levels of managment - all those want to be paid.
What a small customer is for a big vendor can be a big customer for a small vendor. So the small vendor is more likely to listen to your needs.
If you are a big company and somehow get too dependent from a very small company, you could take over more easily.

And BTW: There are more smaller vendors than big ones, so the set of applications to choose from is significantly higher if you consider also the small vendors.

Related posts: Small Business Boom, Scope of IT projects, Paying for free and Open Source, IT Outsourcing, IT projects cost explosion, The Open Source idea.

2010-07-01

Small Business Boom

If boosted by the economic crisis or not, in my neighbourhood I can observe more and more people becoming self-employed building their real own company or just getting freelancers.

What this usually brings is more flexibility and a low budget - at least at the beginning.

Classical style of IT then:

Internet ADSL connection to home office
E-Mail (along with spam filtering) hosted at the Internet provider
Single notebook or desktop PC with some backup strategy or a dedicated server + desktop pc + laptop (something like this). Newer Internet provider modems are even shipped with an option to plugin an external harddrive that is directly offered as a network storage service for connected (W)LAN-devices.
All-in-one printer-scanner-fax devices for doing those most important office operations dealing with paper where still necessary. Usually small and compact devices do not occupy too much space and can handle the small amount of paper in a modern office.
Contacts are saved in the address books of the used email-client, in some cases additional simple local XLS files or Access databases are used or also free online services (but only surprisingly seldom - I guess people do consider their business contacts as a company secret and do have privace concerns).
Office application package is intensively used for writing letters (where still needed), contracts, agreements, invoices and the like.
PDFs are created from the office documents written or scanned documents are saved in PDF format for (long-term).
Sector or branch specific software applications (e.g. banking or insurance agency tools) move more and more in the direction of being online services (web applications) rather than applications that need a local installation.
With a smartphone they can answer emails also while on the road which is crucial for a one- or two-man/women show.
Appointments are managed in the smartphone with the smart phone's own application, Google Calendar or in a classical pen & paper style (what is actually used is mostly depending on people in the company and branch).

I can see such constructs from 1 to 3 or 4 people in my local area. Some of them are considering a move to Linux and I already helped a few building their home-office-desktop on Linux. And lately there are coming more and more asking for Linux...

Related posts: Why Linux?, Going Linux, Why I switched to Ubuntu, The small software vendors.

2010-06-24

Popular Java myths

After developing more than 10 years mostly in Visual Basic (classic), VB Script, VBA etc I started moving to Java after a long evaluation period of different languages about 2 years ago (see also "The programming language") .

Since then when talking with customers, .NET people and even Java folks people come across again and again with the same arguments against Java that are simply wrong. After discussing and researching these arguments a lot of times I am really tired of explaining so this post will hopefully save me from that in the future.

BTW: In discussions you have to distinguish between the Java as a platform (JVM) or the Java language. There are a lot of other languages like Scala, Groovy, JRuby (Ruby interpreter) or Jython (Python interpreter) and others. That the JVM is very popular and far from being dead is not taken into doubt by most people, not so for the Java language.

But why don't these Java language myths finally die:

Java is dead.
The argument usually comes from the fact that a long time passed since the last major release (Java 6 Update 20 is current at this time) and that they don't see big new stuff coming. At this point have you ever considered C(++) dying? - Or Microsoft Windows? No big changes for many years there either!
There are other languages that evolve very fast - but take into consideration that most of those languages are very new in relation to Java and there is still much work to be done. Of course with evolution of a language there is legacy generated and it gets more difficult to introduce major new stuff. The newer languages will see the same happening as these problems affects any software getting into age.
But: It means, Java is proven and stable and I am happy that the language is not changed or enhanced by running after hypes. I really like the decision to think well before really changing a big thing (like introducing closures).
Another reason why people told Java to death is citing the TIOBE or other indexes showing Java loosing popularity or market share. If you examine how these statistics are built you always find that they are not complete and just investigate a few parameters (like new items in Google search results for example). When I heard the last discussion about TIOBE, Java has fallen on position 2 behind C - now it is back on top again although - according to TIOBE - it still looses popularity (which is logical to me because a lot of new other languages are running on the JVM attracting especially Java developers). On the other hand tht C# is gaining, does not necessarily mean that it is better than Java. Windows developers didn't get major new stuff for about 10 years and basically Microsoft is telling them to move.
And it remains the question if new is always better, a lot of companies heavily rely on the stability of Java and the long-term return on investment (ROI).
Besides, although people say, Java is dying, there is so much daily news on Java that I simply can only follow the biggest news. Java land is soooo large and the community is so huge.
Last but not least: Because there are more operating systems around than ever, platform independent development is getting more important (as developing separately for each platform is costly) - well this is a plus for all languages based on the JVM.
Java is slow.
There are 3 groups of people saying this. The first group is talking about the startup times and the second is comparing with C(++).

Regarding the first group: These are mostly people on Windows using Java applications just occassionally. Yes, the JVM takes a while to load (which BTW should be addressed in Java 7) but this applies also for the .NET runtime or other big libraries used in other big applications. The point is, that Windows tends to load everything Windows-related already on Windows startup and if an application using the .NET runtime already then of course the next application will start faster. This issues is (at least partly) already addressed because some Java update comes with an autostarter that also loads the JVM at login time. And BTW: Java 6 is much faster than Java 5 and Java on Linux is much faster than on Windows.

Regarding the second group: They usually refer to optimized C(++) code. First to say, most developers do not really performance optimize their code (only when necessary); second, in a lot of cases, performance of the language is not the bottleneck (usually network and HDD speed is - or inefficient algorithms/storage methods) and third, the optimization is done at compile time and at runtime. Runtime optimization is not available for C(++)-programs. So it can happen, that Java is even faster than C(++). But of course, in a lot of cases particular optimizations are written in C(++) and then called from Java to improve the overall performance. Of course, C(++) has the potential to be faster than Java. The write once, run everywhere idea introduces a level of abstraction that surely can affect performance - there is no gain that does not introduce a cost somewhere else. But: For most performance issues the performance of the language itself is irrelevant (I mentioned the real bottlenecks above)! Further, I only met once a C(++) developer who really considered performance on everything he did. Anyway, just because C(++) tends to be the fastest of all programming languages, Java is not slow - Java is faster than most other languages! - See e.g. benchmarks at alioth.debian.org.

Regarding the third group: Those are usually comparing some simple PHP application with some Java EE application that makes use of a component stack that I just get sick when I see it - so no wonder if such a monster app is behaving a little lethargic. Although Java is widely used in the EE world in huge environments, a real lot of connections and a huge amount of data with a huge component stack and a lot of legacy code (and sometimes even still on Java 4 or 5), Java could be used in smaller environments too. Let's say, a typical PHP application contains a lot of DB queries, XML/JSON/HTML parsing and HTML generation. This could be easily done with plain Java also without introducing any particular framework. So most of those people are simply comparing apples with bananas. See also benchmark mentioned before where PHP rates really bad. - That said, according to earlier mentioned real bottlenecks, that does not really matter in most cases.
Java applications need longer time to develop.
Well, this is maybe not a myth, but a tendency. It is true that while a Ruby-Developer might already have finished the task, the Java developer might still be evaluating the right framework and library to use. But this is not due to the language itself. In many other languages you have not the choices you have in Java land. And for development on Windows, many people just rely on the recommendations given by Microsoft. My experience, after I got member of the local JUG and met some Java developers elsewhere at conferences is, that there are really smart people doing awesome stuff and working on big and critical projects and such with product lifetimes beond 10 or even 20 years. Of course this involves a big responsibility and therefore I can see Java developers investing more time into the evaluation of the architecture, used frameworks and libraries and algorithms.
And this does not mean that you can't get a small project quickly up and running the "agile style" (using the libraries and frameworks you are already familiar with without starting to evaluate with Adam and Eve).
Example: Lately I needed a little tool to count all PDF pages of all PDF documents in a certain tree structure (to evaluate needed license volume for OCR processing). In about an hour I had a small tool ready. I was sure, that there exists a tool already that I could use but searching the internet + testing would have been similar amount of work. And if I would have done it with VB on Windows only half an hour for just building a setup that installs the application at client side - but in Java I simply sent the built jar by email and finished. Just run it without the need to install. As another example it took me about 4 days for a prototype of a PDF archiving tool in Swing with embedded PDF viewer and fulltext indexing of the PDF content. Of course this would not have been possible without any experience in Java - any language must be learned first to get really productive. I have a friend who wondered about the long time I spent on evaluation when starting with Java. Yeah, I already can choose between at least 3 great free (see comparison at Wikipedia) Integrated Development Environments (IDE) while on Windows I only have 1 free for .NET in best case (because the most obvious choice here is the costly Visual Studio). Then for thick clients I can choose at least between SWT or Swing for GUI (not to talk about the plenty of choices for web applications). Then there are plenty of logging frameworks and so on. But once you have chosen your preferred toolset, you can use that also if it might not fit 100% best for the next project y after finished project x. And BTW: You could rely on the recommendation of others (if you want to rely on me use NetBeans and/with Swing for thick clients). I myself did not have the appropriate contacts so I went the rocky way.