A while back I mentioned that I was leaving Windows for Linux, I have been very busy at work though so I hadn't had the time to actually install anything on my desktop at work until a few days ago. Because of my line of work, I was unable to use Ubuntu like I had originally planned and had a choice between RedHat Enterprise Linux or Suse Linux Enterprise Desktop. Taking the advice from my friend Sontek I decided to use Suse Linux Enterprise Desktop 10 over RedHat. After some asking around at work I found out where to get my hands on SLED 10 and got to downloading. Unfortunately the most recent version of SLED I found was version 10 ( although I might be able to get 10 SP 2 now).
I had always heard how easy it was to install SLED 10 and how well most hardware was supported. It is actually pretty nice on the hardware support... if you are using the latest version (10 SP2). I, on the other hand was only using version 10.0. I popped in the 1st install CD and rebooted my machine. It booted onto the Suse installer where it stalled for a few seconds and dropped into the console installer saying it couldn't find CD1. I checked the md5 sum of the CD, it was fine, so the installer must not be recognizing the CD. I didn't have time to investigate until the next day so I went home without Suse installed.
The next morning I did some research and discovered an issue with some motherboards not actually running a real PATA controller and instead handing the duty off to a host controller. Because of this, the default modules loaded up by the installer weren't enough. The fix was easy enough though, I just loaded a few pata modules and the CD recognized properly. After that, the install was a breeze albeit very slow.
After about an hour and a half the install was finally complete and Gnome booted up... unfortunately the video wasn't recognized and was not displaying correctly at all. I squinted at the screen for a second and switched over to a virtual console and booted up Yast. Suse wasn't recognizing my video card correctly and had the color settings wrong so I fixed that and restarted Gnome. OK, no we are good. EXCEPT... now my Ethernet connection is not being recognized. Apparently the NIC I was using needed a module that wasn't in the 2.6.16 kernel that was installed. After some research I found out that I needed the e1000e module that was introduced in the 2.6.23 kernel!
No big deal though, since I want to learn more about Linux I got my chance to try out compiling my own kernel! So I jumped onto my laptop and downloaded the 2.6.25.4 kernel and went through the the how to at Howtoforge. I actually found the process to be very interesting and a great learning process for myself. Obviously I'm still a kernel noob but at least now I have some experience compiling my own kernel. After I compiled the kernel and got the GRUB settings right I restarted Suse into my brand new kernel! After a successful login I was ecstatic I actually got a working compiled kernel!
That leads me to where I am today with Suse, my first install and a kernel compilation later everything seems to be working out well. There are some things I don't like about SLED so far, but I'll write those up later after I've had some time to use SLED and get used to it. This experience has been a good one for me though as it has taught me how to troubleshoot issues better and introduced me to compiling my own kernel. After all that I'm ready to install openSUSE 10.3 on my desktop at home!
Wednesday, May 21, 2008
Saturday, May 10, 2008
Eclipse
I've been an Eclipse user ever since I started programming in Java *way* back in 2006 and I've been very happy with Eclipse ever since then. I have to admit that I've used Netbeans a few times before, but I've always preferred Eclipse to Netbeans, mostly for the wide array of plugins available for Eclipse. Since Netbeans 6.1 has come out I've been tempted to jump over and compare the two yet again. This got me thinking about what I like about Eclipse and also what has been annoying the hell out of me the past couple weeks. So here are a few things that have been driving me crazy about Eclipse.
1. Project Explorer Forgets
Maybe this is an incorrect setting or something but why does my project explorer forget where it was when I restart Eclipse? If I have a project workspace setup and have tab open, I'd like to have the project explorer also remember where I was in the folder system. It gets really old to have to navigate back to the folder I was looking at when I restarted Eclipse to get a new plugin. This really drives me crazy since the projects I have are pretty large and it makes Eclipse lag a bit while it opens the folder tree.
2. Helpful Tips
I love the fact that I can hover my mouse over a class and see the default Javadoc for that class, but I have one serious complaint about this tool tip. Why is it not HTML? Javadoc allows you to link to other classes' Javadoc using HTML tags as well as the {@link} tag. Why can I not click on it when I focus on the tool tip? I know I can ctrl+click on the class to go there, but you are ignoring all the HTML rendering that can be done with Javadoc! This is annoying as hell! Please Eclipse, take a hint from Netbeans and fix this!
Off the top of my head those are my most annying complaints, but as I run into more issues with Eclipse I'll post my issues here.
1. Project Explorer Forgets
Maybe this is an incorrect setting or something but why does my project explorer forget where it was when I restart Eclipse? If I have a project workspace setup and have tab open, I'd like to have the project explorer also remember where I was in the folder system. It gets really old to have to navigate back to the folder I was looking at when I restarted Eclipse to get a new plugin. This really drives me crazy since the projects I have are pretty large and it makes Eclipse lag a bit while it opens the folder tree.
Update: Thanks to George's awesome comment, my problem has been solved! Eclipse has had the "link with editor" button for a while now and it keeps the navigator tree open to the files you have open. Thanks!
2. Helpful Tips
I love the fact that I can hover my mouse over a class and see the default Javadoc for that class, but I have one serious complaint about this tool tip. Why is it not HTML? Javadoc allows you to link to other classes' Javadoc using HTML tags as well as the {@link} tag. Why can I not click on it when I focus on the tool tip? I know I can ctrl+click on the class to go there, but you are ignoring all the HTML rendering that can be done with Javadoc! This is annoying as hell! Please Eclipse, take a hint from Netbeans and fix this!
Update: Eclipse 3.4 Ganymede fixed this problem. Go get Ganymede and enjoy all the new features. (I like the new update system)
Off the top of my head those are my most annying complaints, but as I run into more issues with Eclipse I'll post my issues here.
Tuesday, May 06, 2008
Hasta la Vista, Windows
Dear Windows,
You are a long time pal of mine, we've been friends since you were just 3.1. I've grown up with you on my computer and we have many fond memories together (except during your ME years), but I have to tell you something old pal. I've found someone else. I know, I know, this may come as a shock to you, but ever since you grew out of XP and into your new Vista body things just haven't been the same. Its not you, its me... ok its you too, but you just don't have the tools and stability that I need. Plus I'm tired of telling you that I'm your Genuine® friend all the time. Why are you so insecure about that?
Now I know who you think I've found, but you're wrong. They may have better looks then you (sorry) and seem to be cooler than you (again, sorry) but they are even more controlling than you are. I just can't be with an operating system that is so willing to lock me down in both hardware and software. Instead, I've found someone else, and they aren't afraid of a little choice. And not just between Home Basic, Home Premium, Business, or Ultimate (what do they all mean anyway?).
I'm sorry Windows, but I will not be installing another version at home again and I will avoid you as much as I can at work as well. Of course, we'll see each other from time to time since I have to make sure my code works with you, but thats all it will be. Linux is my new best friend and we are happy to have superior tools and the freedom to use and modify them how we choose. Its been fun Windows, but your day has passed.
You are a long time pal of mine, we've been friends since you were just 3.1. I've grown up with you on my computer and we have many fond memories together (except during your ME years), but I have to tell you something old pal. I've found someone else. I know, I know, this may come as a shock to you, but ever since you grew out of XP and into your new Vista body things just haven't been the same. Its not you, its me... ok its you too, but you just don't have the tools and stability that I need. Plus I'm tired of telling you that I'm your Genuine® friend all the time. Why are you so insecure about that?
Now I know who you think I've found, but you're wrong. They may have better looks then you (sorry) and seem to be cooler than you (again, sorry) but they are even more controlling than you are. I just can't be with an operating system that is so willing to lock me down in both hardware and software. Instead, I've found someone else, and they aren't afraid of a little choice. And not just between Home Basic, Home Premium, Business, or Ultimate (what do they all mean anyway?).
I'm sorry Windows, but I will not be installing another version at home again and I will avoid you as much as I can at work as well. Of course, we'll see each other from time to time since I have to make sure my code works with you, but thats all it will be. Linux is my new best friend and we are happy to have superior tools and the freedom to use and modify them how we choose. Its been fun Windows, but your day has passed.
Monday, May 05, 2008
Peer Review Your Tests
Software review has been around since the 70's, but one place I see it skipped over often is in the test world. Why would anyone want to peer review your test cases? The answer to that is, why wouldn't you?
It seems to me that many testers don't have their code reviewed because it often does not intermix with anyone else's code. This is one problem that leads you to owning "your" parts of the code and ignoring "someone else's" code. This creates a sort of hands off environment where people begin to guard their code and resent when someone else is prodding at its inner workings. This is where a culture of voluntary peer reviews can help bring the test teams together into a more cohesive, and open unit.
I say voluntary because formal reviews do not sit well with developers (or anyone else involved for that matter), because of the stiff formality and time spent reviewing. The best way to get a team of developers reviewing each other's code is to introduce it and start using it yourself first. Once the benefits become clear, the stragglers will be interested. Also, by keeping the code reviews informal and voluntary, the reviewee's attitude is much different than if they were being forced to do a review.
So what benefits does a test team gain from using a peer review system? Just the same as they have been argued for developers. A good peer review setup will help keep your test cases consistent and readable among the differing 'silos' of tests in your suite. Also, by showing your code to your other teammates they can save you time debugging if they spot a problem with your testcase. This, to me, is one of the most valuable assets to a code review system. If someone can point out a problem before I waste time on it, I'm eternally grateful. The second most useful aspect of code reviews have absolutely nothing to do with finding bugs. The side effect of doing a peer review comes in the form of skill transfer. If I'm working on some web service tests and I'm reviewing tests for web services security, I'm going to pick up how their tests work as well as how the web services security works. This can also help foster another important and very useful activity within the team, mentoring.
While there are many more reasons why you should implement an informal peer review system, I'm going to leave what I have at this and open up to discussion on peer reviews. How have they worked for you and how did you implement a code review system? Let me know in the comments.
It seems to me that many testers don't have their code reviewed because it often does not intermix with anyone else's code. This is one problem that leads you to owning "your" parts of the code and ignoring "someone else's" code. This creates a sort of hands off environment where people begin to guard their code and resent when someone else is prodding at its inner workings. This is where a culture of voluntary peer reviews can help bring the test teams together into a more cohesive, and open unit.
I say voluntary because formal reviews do not sit well with developers (or anyone else involved for that matter), because of the stiff formality and time spent reviewing. The best way to get a team of developers reviewing each other's code is to introduce it and start using it yourself first. Once the benefits become clear, the stragglers will be interested. Also, by keeping the code reviews informal and voluntary, the reviewee's attitude is much different than if they were being forced to do a review.
So what benefits does a test team gain from using a peer review system? Just the same as they have been argued for developers. A good peer review setup will help keep your test cases consistent and readable among the differing 'silos' of tests in your suite. Also, by showing your code to your other teammates they can save you time debugging if they spot a problem with your testcase. This, to me, is one of the most valuable assets to a code review system. If someone can point out a problem before I waste time on it, I'm eternally grateful. The second most useful aspect of code reviews have absolutely nothing to do with finding bugs. The side effect of doing a peer review comes in the form of skill transfer. If I'm working on some web service tests and I'm reviewing tests for web services security, I'm going to pick up how their tests work as well as how the web services security works. This can also help foster another important and very useful activity within the team, mentoring.
While there are many more reasons why you should implement an informal peer review system, I'm going to leave what I have at this and open up to discussion on peer reviews. How have they worked for you and how did you implement a code review system? Let me know in the comments.
Sunday, May 04, 2008
Follow Your Users
Thanks to a tweet on Twitter I came across an interesting article on why companies should pay more attention to their customers complaints. But it doesn't stop just at companies keeping track of their brand reputation among their customers, this can (and should) be done much more often than it is today. Here are a couple people and groups that I think should be interested in what complaints they are receiving.
Open Source Projects:
If you run an open source project, you should be keeping track of what people are complaining about. Many open source projects get lulled into believing that if their users have a problem they will fix it and submit a patch for it. While this definitely happens, there are many more users out there that either just don't have the time or skills to fix it, or they may not even know that they can fix it themselves. This also leads me to another issue many open source projects have, it seems that many projects think that if someone has a complaint but is unable to fix it, they will go to the forums and start a discussion about this. Again, many people will simply post their complaint to their blog or Twitter and leave it at that. This isn't a bad thing, it just means that we need to go out there and actively be looking for what people are complaining about.
Product Managers:
Every product manager (software and non-software) should be keeping track of what people are saying about your product. While most products spend a load of money on doing customer research and analysis, it really doesn't cover you. While many people may fill out a survey about your product, they don't get to express their true feelings about it unless they get to say it in their own words. Product research will only get you so far, let your customers tell you what they think of it for free!
Specification Leads:
You definitely need to be listening to what users are saying about your previous specification revision or similar specification if its a new spec. It seems to me that most specifications written seem very out of touch with how people are working with the last revision. It took the EJB specification 3 revisions to begin to even remotely come close to what users wanted. If the spec leads had been listening to what users were saying about the EJB specification we could have avoided much of the hassle that was EJB2.
While there are more places listening to customer/user feedback is important, I'm going to leave it at these three. What's most important to remember is that you should be listening to what people are saying about your product, project, or whatever else it is. You need to listen to what they are saying and actually do something about it. You also should not be afraid to talk with your users and let them know that you do care and that you do know they exist. What other places could you find this helpful in? Leave some comments and let me know what you think.
Open Source Projects:
If you run an open source project, you should be keeping track of what people are complaining about. Many open source projects get lulled into believing that if their users have a problem they will fix it and submit a patch for it. While this definitely happens, there are many more users out there that either just don't have the time or skills to fix it, or they may not even know that they can fix it themselves. This also leads me to another issue many open source projects have, it seems that many projects think that if someone has a complaint but is unable to fix it, they will go to the forums and start a discussion about this. Again, many people will simply post their complaint to their blog or Twitter and leave it at that. This isn't a bad thing, it just means that we need to go out there and actively be looking for what people are complaining about.
Product Managers:
Every product manager (software and non-software) should be keeping track of what people are saying about your product. While most products spend a load of money on doing customer research and analysis, it really doesn't cover you. While many people may fill out a survey about your product, they don't get to express their true feelings about it unless they get to say it in their own words. Product research will only get you so far, let your customers tell you what they think of it for free!
Specification Leads:
You definitely need to be listening to what users are saying about your previous specification revision or similar specification if its a new spec. It seems to me that most specifications written seem very out of touch with how people are working with the last revision. It took the EJB specification 3 revisions to begin to even remotely come close to what users wanted. If the spec leads had been listening to what users were saying about the EJB specification we could have avoided much of the hassle that was EJB2.
While there are more places listening to customer/user feedback is important, I'm going to leave it at these three. What's most important to remember is that you should be listening to what people are saying about your product, project, or whatever else it is. You need to listen to what they are saying and actually do something about it. You also should not be afraid to talk with your users and let them know that you do care and that you do know they exist. What other places could you find this helpful in? Leave some comments and let me know what you think.
Subscribe to:
Posts (Atom)