Mar 14 2013

Why is Google giving up on Google Reader?

Category: English posts,TechnicalIuliana @ 9:32

This morning I started my day with a sad news: Google is shutting down Google Reader on July 1st, 2013. The reason for this is that, I quote: “usage of Google Reader has declined, and as a company we’re pouring all of our energy into fewer products.”

The fact is that I have no experience in statistics, I have no idea how many people actually use Google Reader on their computers or on their phones. On my phone, I don’t have any reader fo that matter. What I do know is that Google Reader is a practical, stable product which I have been using for free since 2007. There is no reason to give up a practical and stable project, at least not from my point of view. But considering the fact that Google is a huge company which offers hundreds of services and products, they might actually have some really logical reasons for this. Maybe they are preparing a different feed reader for us, maybe this move is just like taking candy from a baby to convince him to do his homework. Maybe by doing this to us Google is trying to convince us to pay for this wonderful service we have been using for years. And you know what? I have noting against it. I would pay a monthly fee for this service, because I like having all my stuff in the same place and because Google Reader is perfectly integrated with other Google services that I use.

I don’t think that Google is going to shut the reader down, most probably it would rebrand it and give back to us for a fee, or it will integrate it into some other service. But, I guess we’ll just have to wait for the 1st of July 2013 when their possibly “evil plot” will be revealed. :)

Mar 06 2013

Google can only do so much

Category: English posts,TechnicalIuliana @ 11:31

What do you do when you get a creepy Java exception telling you something that has nothing to do with what actually causes it? And how do you know that the cause is a different one.

This is one of those cases when Google can only do so much. A lot of developers with too much time on their hands might have written on their blogs how they solved that error, but it does not apply to your case. More than that, doing something similar on your project just caused a different problem.

So what can you do? Well, before there was Google, there was something everyone with more experience than you would tell you: RTFM = Read The Fucking Manual!!! When you have a problem Google cannot give you a fast solution for, you have to go deep in the details of your application. What does this mean? Take a look at what technologies you are using and check if you are using them right. If you are a lazy and comfortable programmer, like most of us are, you probably just copied the default settings from the official site or some blog where some other developer with too much time on his hands wrote how he used it. And most of the times, that information is not so recent and internally some changes have taken place that make that specific tool behave differently.

Don’t get me wrong, I am not a pioneer of reinventing the wheel! But sometimes instead of searching mindlessly on Google, is easier to try to understand the technologies you are using and work with them they way the manual says you should.

This is a the main difference between a mature developer an a young one. The young one thinks that everything he needs to write an application or solve a problem is one-click away. The mature one knows that understanding the technology can spare you a lot of … clicking time.

Dec 07 2012

Compiling, compiling … done.

Category: English posts,TechnicalIuliana @ 14:13

As you noticed from my previous post, a few days ago I started updating a Gentoo VitrtualBox machine.
Right after the update used:
#emerge -av –depclean

And that’s when all went to hell. Apparently a lot of my packages were considered unnecessary and were unmerged. Among them some dependencies for the VirtualBox modules which made my virtual machine forget about the graphical interface. The possibility of displaying a log on the five inch window to see what the problem was , was not an option so the first step was to fix the system a little so that I could at least have access to a bigger screen.

The solution was simple in my case, just emerge –sync and emerge world again . And surprise!! a new version of Kde was available, 4.9.4 and the system proceeded to installing it. So I said, what the hell let it do it! After a few hours of torture, during which I searched for a solution to make the VirtualBox modules work in order to be able to make my virtual machine interact friendly with the underlying OS, a Windows 7, I found a guy on a forum which had a similar problem and his solution was to upgrade the kernel. So I checked the version of kernel I was using. Indeed was an old one. A new one was not such a bad idea. So I downloaded the new sources and got to work taking the same steps specified by the manual. By the end of the night I had a fresh 3.5.7 kernel and the same problem with the VirtualBox modules. I unmerged them (virtualbox-guest-additions and virtualbox-modules), emerged them again. But the situation was the same. I was going out of my mind, not knowing what the problem was. So at the end of my patience, I asked an expert: Rpx. Based on a piece of message found in a log file in /var/log “vbox disagrees about version of symbol module_layout”, he concluded that my VirtualBox modules were compiled with a different kernel dependency. Well, that’s was all I needed.

I wend on and recompiled the kernel using:
#genkernel –menuconfig –bootloader=grub all
And when configuring it I took a look here and selected the options recommended for a VirtualBox machine. The kernel was compiled, I just unmerged and remerged the virtualbox stuff and instead of following the steps in the previous link I just followed the instructions displayed in the console at the end of the compilation for virtualbox-guest-additions.

I restarted the system and… voila! My virtual machine is up and running and interacting with Windows just fine.

Disclaimer:This is not a tutorial on how to fix a Gentoo VirtualBox Machine, it is just a post in which I brag about the fact that I can do it. :D You could take it as an advice to Read The Fucking Manual!, because that’s what helped me in the end.

Tags: , , ,

Dec 05 2012

Emerge kinfocenter-4.9.3 fails [Simple Solution]

Category: English posts,TechnicalIuliana @ 12:31

A few weeks ago I switched back to Linux at home, because the training for the Spring Certification exam ended (setting up the official working environment on Linux was a pain, that’s why I worked on Windows for a while). At home I have SolusOS, which takes care by himself of updates and stuff( I chose because it was more suited for a laptop). Switching back to Linux at home, made me fell like working on Linux at work too, so I remembered I had a VirtualBox machine with Gentoo on it. So I started it and begin updating it, because the poor thing was not used in a while, so this process was unavoidable.

I intended to run the basic command for updating a Gentoo system, as recommended on their official site:

# emerge --update --deep --newuse world
# emerge --depclean
# revdep-rebuild

Unfortunately it was not so easy, because I have stumbled across this problem. So kinfocenter-4.9.3 failed to compile and the problem was a missing library, obviously, but the log message was not very clear. I have to mention that when it comes to Linux I am not such a guru, so after trying the solution on the forum and failing miserably, I stared trying anything just to make this work.

The problem was obviously with the media-libs/mesa library. I had the 9.0 version installed already and as I figured from the forum topic kinfocenter-4.9.3 depended on mesa-8.0.4-r1. Apparently the solution was simple, just unmerge the current version and install the required one, the old one.  Which I did, meaning I unmerged mesa-9.0. And after doing that, I had an idea.

What  if I used revdep-rebuild? Because that’s what the manual says it does:

revdep-rebuild scans libraries and binaries for missing shared library
dependencies and attempts to fix them by re-emerging those broken bina-
ries and shared libraries. It is useful when an upgraded package
breaks other software packages that are dependent upon the upgraded

And I used it. And it worked, kinfocenter-4.9.3 was installed successfully and is working fine with mesa 9.0 which was automatically installed by revdep-rebuild. :|  So my solution to fix this is made of two steps:

# emerge --unmerge media-libs/mesa
# revdep-rebuild

After revdep-rebuild finished I continued with the update of the system, and so far all is working great.

Sometimes it’s better not to be a guru in a specific domain, because it gives you the opportunity to find new and simple solutions.

Tags: , , , , ,

Nov 08 2012

Learning Spring, part VI

Category: TechnicalIuliana @ 15:44

This won’t be a post  about a problem or a question, but about an observation.

When I took the spring Core course in Belgrade this June, in the Chapter about data access the jdbcTemplate instance was created like this:
Java code:

//random DAO class
private JdbcTemplate jdbcTemplate;
public void setDataSource(DataSource dataSource) {
    this.jdbcTemplate = new JdbcTemplate(dataSource);

Xml configuration:

<bean id="dataSource" class="..." />

After that I read Spring in Action, then the Spring reference and everywhere when given an example on how to use jdbcTemplate, the instance was created and injected like that.

And I am confused. If jdbcTemplate instance is thread-safe once configured, is recommended to not create one for each use and is stateless (does not maintain any conversational state) why don’t we just create it as a singleton bean and use it as such?
Sample of my code:

//random DAO class
private JdbcTemplate jdbcTemplate;
public void setJdbcTemplate(JdbcTemplate jdbcTemplate) {
    this.jdbcTemplate = jdbcTemplate;

Xml configuration:

<bean id="jdbcTemplate" class="org.springframework.jdbc.core.JdbcTemplate">
   <constructor-arg ref="dataSource" />

Tags: ,

Nov 06 2012

Learning Spring, part V

Category: TechnicalIuliana @ 10:37

<ref local=””/> vs. <ref bean=””/>

So here is the conclusion of this post, which was debated with my friend MARIANUL also.

The only difference between the two is syntax and  behaviour at application design time, when each of them helps you , the developer, in its own way, to figure out if the references are valid or not. At run time, there is no difference: all beans are created and reside in the same application context so the references are correctly solved.

So yeah, this is it. Simple as that. So ignore all the blog posts where you are told that code does not compile because of XML parser errors and if you doubt my findings too, dare to test and draw your own conclusions. This is what I did. :)

Tags: , , ,

Nov 05 2012

Learning Spring, part IV

Category: TechnicalIuliana @ 13:05

<ref local=””/> vs. <ref bean=””/>

So, when should we use one or the other and why?

First, I’ll offer you a link to the official Spring reference documentation related to this subject.  Basically:

Specifying the target bean through the bean attribute of the tag is the most general form, and allows creation of a reference to any bean in the same container or parent container, regardless of whether it is in the same XML file. The value of the bean attribute may be the same as the id attribute of the target bean, or as one of the values in the name attribute of the target bean.


Specifying the target bean through the local attribute leverages the ability of the XML parser to validate XML id references within the same file. The value of the local attribute must be the same as the id attribute of the target bean. The XML parser issues an error if no matching element is found in the same file. As such, using the local variant is the best choice (in order to know about errors as early as possible) if the target bean is in the same XML file.

Then we will play with some source code.
Continue reading “Learning Spring, part IV”