Good:

• Seafile – The guys that work on this project are freaking great! I can’t say enough good things about Seafile.
• CeGCC
• Berkerpeksag/github-badge

Bad:

• XBMC [They will not take bug reports or feature suggestions]
• Tiny-Tiny RSS
• OpenStack Folsom Install Guide [The official documentation doesn’t agree with some of the suggestions, and I’ve tried to point this out]

I understand that these tend to be non-work projects, and that it can take a lot of work to maintain a community. But its rather frustrating that people who attempt to chip in to help make the system/application/code better are treated rather roughly.

• There is a new change to how network devices are named. This may change your network device from eth0 to something like env10p0.
  http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
• Archlinux is very similar to Gentoo, but it is based on a script to install everything.
• 2to3 is a python script that will convert a python script from a version Python 2.0 to a 3.0 compatible script.
  • One major difference between 2 and 3 is that the print statement became a function, thus requiring parenthesis.
• It is easier to hard code the Python 2 environment, rather than to convert the script into a Python 3.0 script.
  • #!/usr/bin/env python2.7 [or whatever Python 2 environment that is installed] should be used in the shell definition of the script.
• OpenVAS- Open Vulnerability Scanner: I haven’t tried this yet, but this is a neat utility that can help you keep tabs on the software you currently have installed and the possible vulnerabilities that they may have.
• Always snapshot your VM after you finish major installs. [This saved my butt this week]
• Ansible -  This looks like a nice Open Source version of HP Operations Orchestration.

It might be a better use of my time to do periodical reviews of my current skillsets and recent tasks rather than to push forward blindly.

I’m not giving up on learning new things. I’m just not going to limit myself to a list.

Some of the technologies/tools I’ve been learning lately:

1. OpenStack
2. ArchLinux

Some technologies I would like to learn:

1. Storm
2. Ansible

The major issue of installing OpenStack could be solved through a dedicated install process. However, the larger issue is that the user is allowed to fail so quickly. It’s similar to refusing to validate an email address prior to submission and processing on a website. My suggestion is that many of these issues can be solved by doing step by step confirmations of the process. For example, if you were to install a web framework, the installation process/script should confirm:

1. That a server is installed
2. The installing user has permissions, or can be elevated to the permission level, to install the web application
3. Copy the files over to the web server and start the web application
4. The web application prompts for a configuration on the first run (I.e. Checking for writable permissions at the get go, setting up users, etc.)

Asking a system administrator to do all of these manual confirmations causes quite a few issues. For example, Some web applications have an issue with the database configuration after the web site has been put in use.  Lastly, if a script fails it should fail in a sandbox rather than the live environment. Gentoo sandboxes ebuilds prior to installing the executables on the system.

Another thing to note, if a user is configuring a database on install ask for the host, confirm that the host is enabled, and then allow for a database selection.

For the most part Apache Wicket solves many of the web related issues that J2EE (JSP) has. If you are to follow the prescribed way of doing things, it can actually be quite pleasant. However, there are a few thorny patches with Wicket. I will get to those later.

Wicket In Action like a marriage. During the honeymoon, everything is great. Everyone is happy, and then later discontent grows and things go up and down. However, unlike a marriage, you don’t really get an ending. This is a rather good way to end things, but some of the lesser parts of the book were rather disappointing. One of the big selling points of Wicket is that it is a framework that assumes that the developer has already prototyped the pages in HTML prior to starting with Wicket [The pages are adapted into Wicket-ized and previewable pages]. This upside was enough to ignore the placement of the HTML files, in the class path rather than the web resources section.

I jumped into this book with lots of enthusiasm after reading the introduction. I even bore through some of the non-stated setup issues in the book. The book starts off by creating a project, from scratch, however I went the Maven route (which I discovered is the better way to go). The book mentions maven, but it doesn’t mention how to build your application or to generate a project. I believe that I went the correct way because Maven helped to setup all of the application servers and the folder structures. The book started by having the user to jump in, examine a few code segments, and then to start on a sample (full featured) e-commerces application. The store was oddly pleasant; the goal was to sell cheeses online. The application started from a few sample view pages, it went on to creating a reusable shopping cart, and finally on to a membership mechanism. This is a very straightforward and to-the point way of starting a new framework. It’s already addressing the needs of the majority of its audience.

Another nice thing to point out about the introduction is that it did not try to cover all of the material at once. It would frequently describe what you were doing, but would mention the chapter where the concepts were explained in depth later on. Something that pleased me was that the code listings did not include a listing number. They were place in the correct location of the text. After you’re done with the sample application, you should be quite proud of yourself. This is similar to your first website.

However, the book got a little disappointing when describing the more detailed interworkings of Wicket: sessions, bookmarkable pages, and layering/rendering. The book improves when it gets to the Ajax functionality and a brief mention of dependency injection and Wicket. The book gets a little rough in the Spring through Hibernate sections and then better in the testing section. The book ends in a rather low note on SEO, production configuration, and JMX. If I had known more about JMX, I would have probably had a better opinion of the ending.

Overall I am not sure if I can say that the less than stellar sections of the book were entirely the authors’ or the book’s fault. It quite possibly may be the technology’s fault.  I would strongly recommend the book if you are new to Wicket.

Lastly, here are some direct tips that I had to discover on my own that helped out a lot:

• Use an Apache Wicket Quickstart for Maven: This will generate a sample project with Jetty support.
• Use the WicketStuff annotation MountPoint to define where pages are referenced. This will help to debug and directly navigate to pages.
• When creating HTML pages use the Wicket namespace: <html xmlns:wicket=”http://wicket.apache.org”>

What I’ve found incredibly frustrating is the attitude of many of the interviewers that I have been interviewed by. Most of the individuals whom I have been interviewed by have been highly combative. They want you to prove that you know what they want you to know, whilst simultaneously proving that you would be a good cultural fit. For example, smaller organizations will throw out Google/Microsoft like interview questions just for appearances. Is this necessary for determining the quality of the applicant? I don’t believe that it is. Unless your industry requires every engineer to make close estimations, it appears to me that it is more of a way to build an unrealistic ‘tough-guy’ image. There is absolutely no reason for an interviewer to be combative with an interviewee. The goal, on the company’s side, is to find out if the applicant would provide value for the company. If an individual’s average day is fairly easy going, why make the interview stressful? It’s akin to demanding an auditioning actor to recite the entirety of Shakespeare’s work when interviewing for a non-speaking role in a 30 second commercial.

Another issue that I’ve found is the amount of criticism of interview code. I’ve had a range of this: “code portfolios,” sample programs prior to the interview, temporary assignments, IQ tests, talk and coding, and white board exercises. Only a few of these coding practices are reasonable, the others are unrealistic and stressful. The IQ/aptitude test was a part of the application process at IBM. It was a little silly, and timed, but I guess I was within their upper and/or lower limits for acceptance. The test was online and it was after the interview, so it wasn’t so stressful. I’ve had an organization request a coding portfolio; that is a horrible idea. Portfolios are required of those who do visual work, but code portfolios suffer from a lack of context, industry acceptance, and lack of time to compare and contrast multiple candidates’ submissions. I’ve had to work with one group temporarily [after the interview] as a trial period. This wasn’t so bad for a few reasons, one the company paid for my travel to get me there (going from the US to Europe), was only for a short time and lastly, it isn’t unreasonable to ask for this when considering very long distance applications. However, the downside to this is that it negatively impacts the discreteness of interviewing a new workplace.

I tend to like coding samples prior to the interview. If you’re given a problem set to choose from, it gives the interviewee a chance to emulate the conditions in which they would be working in. The interviewee is able to ponder, on his/her own schedule, about the problem, design, code, test, and package the code. I am not a fan of coding on a whiteboard. It is a completely different experience from how one codes. It strips away the tools and contexts, and expects the individual to perform their tasks in a completely foreign way. If the interviewer was asking for high level details, this request isn’t too far fetched. From my experience, there are a lot of organizations that attempt to have the interviewer watch an interviewee code via a live collaborative editor while on the phone. These are some of the worst interviews I’ve ever had. The task is not humanly possible. The tasks are usually set up in a professor/student manner. The process is usually: a problem is presented, thinking occurs, have the interviewee talk through a problem, code while explaining the code, and to use a foreign editor at the same time. To make things worse, this is all done while the interviewee is holding a phone and typing on a keyboard. It is not humanly possible for an individual to communicate, and solve deep problems at the same time, to make things worse you’re being judged at the same time.

Lastly, I have been asked to code up a problem or two, with the interviewer on a computer. This has been done in a peer-wise and non-peer-wise fashion. Usually this involves a small problem, and you’re given a new project in an IDE. At times, this may be a little tough if the IDE is unfamiliar, but this at least attempts to reproduce the working environment.

What are some of the questions that I would like to be asked?

I believe that an interview should be more for an inquisitive time between an interviewer and interviewee. There is no benefit from trying to make a stressful interview even more stressful via combative techniques. So I think there are a few questions that would make it easier:

1. Ask questions related to the projects that the interviewee has worked on before. [Preferably a non-work based project]
2. Ask about some of the challenges faced on the projects. For example, if the project required a high level of performance, how did they solve the communication issues between components? If the project dealt with numbers or precision or money, ask how they solved the issues with floating point math.
3. Ask what an individual project taught the interviewee.
4. Ask about times where the interviewee has conflict with another coworker; ask how he or she would have resolved the issue. (Don’t ask for opinions or gossip surrounding the conflict)
5. Ask about what blogs/technical content they follow.

These questions get the interviewee to talk more about what they should be confident on talking about. The questions also demonstrate the ability to work with others, willingness to adapt, interests, technical strong points, experience, passion, and potential weak points. Lastly, to the interviewer, consider the individual that you are communicating, with being hostile won’t do you any favors if you have to work with them later.

1. Need to change your contract during the time you have the car? Call up Budget and you’ll be sent to sales. This is a new sales avenue for them. They will make an adjustment to the contract at a new rate and charge a fee to do this [if you prepaid].
2. Have a misconnect or a schedule change with a flight? Despite that they work alongside the airlines, they do not acknowledge that misconnects and huge delays do happen.
3. Mysterious dings/scratches. I returned my car in ATL last Thursday evening. A ding was found on a wheel well. [How this got there is beyond me and there was no indication of neighboring marks that would give more hints to this] The issue here is that no inspection was done after receiving the car. They agents refused to inspect the car and demanded that I sign the damage form blank. How this will be billed/handled by insurance or credit card is beyond me.

More information on the second complaint: I’ve had an issue or two where I’ve had to change my contract/arrival times with the rental company. I’ve never been able to get to local branch where I reserved my car. All of the listings for that location are SEO optimized to go to the national number, which then forwards you to sales rather than customer service. After getting tired of the whole pricing, I was told by the agent at the ROC Budget Rental company that the new price was based on “Market Demand.” That ignores the fact that by not picking up the car they now have more supply and less demand. They attempted to reprice a week long rental that was originally $172 to $530+. Finally, after threatening to cancel my reservation for next week, he made a (his words) “manual one time price fix.” I knew the market price for a last minute car rental. It was $350 via Alamo. Are they any better? We’ll see.

• If the Nvidia package has difficulty finding the version number for the kernel, which is an issue for 3.7 and higher then link the Versions.h file to /usr/src/linux/include/linux/.
• If you have “AutoAddDevices” in your xorg.conf file, your mouse and keyboard may not be found when X starts up.
• For Gentoo users and people who manually build their applications, if you get an error on the build, make sure you that you reduce the number of concurrent builds when searching for the error. This is a matter of reducing the argument -jXX to -j1. This will help you resolve an issue where groupware_dav in the KDEPIM-runtime package fails to build. The solution to that issue: The build was having an issue with a libsasl library, and required for a revdep-rebuild.
• For those who have an NVidia Optima: you may get an error that “Cannot load glx on :0.” This causes for the graphics performance to be less than stellar, and for KDE Desktop Effects to not operate. To resolve this issue: Make sure that the Intel/Mesa graphics driver is reinstalled and to switch the default OpenGL reference to be Xorg-server rather than NVidia. [Use the "eselect opengl set " command to accomplish this] Setting the OpenGL setting will not affect Bumblebee’s OpenGL switching.

I agree with a few of the author’s points on what causes bad code/designs, however I believe that the author misses the point when he relates it to the content of textbooks. Textbooks are meant to be condensed learning resources. They tend not to be fluffy and full of relatable content. With a textbook one should be able to reliably consume the facts associated with the subject, and not the current commentary of the industry surrounding it. Textbook-code that was relatable to practice would be an inefficient method of delivery to the reader. Unless it is briefly mentioned, it would be silly and unprofessional for a computer science textbook to make snide remarks on real-world coding practices, gender politics/representation in the computer industry, how most technologies are not used fully, or any other non-topic rants within a textbook. A good text book will stand the test of time.

In short, I believe that Mr. Mandl, the author, would be more interested in industry and learning social trends.

• Encourage Reuse later on
• Dramatically increase build times
• Increase the amount of time needed to perform version control [A bigger code base takes longer to examine]
• Reduces one’s ability to navigate through the code.
• Increase the executable size
• Increase maintenance times

So in short: If the code is no longer needed and used, remove the dead code. If you’re using source control properly, the change can be reverted.

If the team you are working with still insists on orphaning code, at least have them to agree on periodic spring cleaning of the project.

Good News to those who use Maven and are working on J2EE web projects in IntelliJ: Here’s a guide.