Then you might appreciate this:
Conservative. Idaho. Software engineer. Historian. Trying to prevent Idiocracy from becoming a documentary.
Email complaints/requests about copyright infringement to clayton @ claytoncramer.com. Reminder: the last copyright troll that bothered me went bankrupt.
Showing posts with label software engineering. Show all posts
Showing posts with label software engineering. Show all posts
Sunday, September 18, 2016
Monday, October 10, 2011
The Severe Shortage of Skilled and Experienced Engineers
A reader pointed me to this article at October 3, 2011 WBUR:
Businesses whining about a shortage of skilled engineers are making excuses, hoping that the government will again let them bring in H-1B visa holders to work for $2000 a month.
But according to a new report by the financial services firm, Jones Lang LaSalle, high-tech jobs are growing nearly four times faster than the national average. The report also shows that venture capital is driving the job boom, with high-tech accounting for 50 percent of total venture capital funding over the past year.One comment trying to argue that there is indeed a shortage of skilled engineers says:
Companies say it’s difficult to find and recruit talent, because there is a dearth of qualified engineers.
We're not looking for specific skills, just someone with current skills and the willingness to learn what we do. (Hey, you do PHP, Python, Perl, Java, that's great...if you want to learn Ruby on Rails too, then we've got a job available now).And yet I was just turned down for a job because they wanted someone with PHP experience. I've written server-side CGI scripts in Perl, and ksh, and I've been writing server-side Java for a couple of years now...but there isn't time for me to learn one more language. Do you have any idea how many programming languages I have learned since 1971? So many that I can't even give you a rough guess, but taking off my shoes doesn't help on the count.
Businesses whining about a shortage of skilled engineers are making excuses, hoping that the government will again let them bring in H-1B visa holders to work for $2000 a month.
Friday, April 22, 2011
I Could Get Addicted To Linux Again
I was trying to get a Linux script written today at work that to be honest, I should not even need to be writing. I'll leave out the gory details, but previous people who no longer work there have left us a development environment that would have been perfectly acceptable in about 1975, and even somewhat excusable in 1985. (I was working in the industry both years, so I know of what I speak.) Today? Not even slightly.
Anyway, the script that I was writing was really not that complicated, but using vi (or vile, as it is properly known) makes me rapidly lose interest in doing anything, and I am not having any luck installing any of the minimal sets of emacs on the Linux boxes we use. (A good friend provided me the microEmacs source that he uses, but whatever variant of Linux we have at work does not have the term.h file defined--which I thought was about as vanilla as you could get when it comes to Unix/Linux variants.) Aggravating matters, I am using telnet to connect up, and it is astonishing how slowly everything seems to work that way.
I could put in a request to have our operations sorts install emacs there, but it would probably take a year or more for it to happen. You know the way that Dilbert parodies the security paranoia of Dilbert's corporate IT sorts? It is perilously close to being that way--although admittedly, we are running a prison system, so a fair bit of paranoia is probably appropriate.
Anyway, I mentioned a few days ago that I was replacing the soon to be dead hard disk on my older notebook so that I could run Windows and Ubuntu Linux dual boot. (The soon to be dead hard disk is now a 20 GB portable USB drive.) This is a pretty obsolete notebook--a Compaq NC6000 that HP gave me in 2007 when they upgraded my work notebook. Yet Ubuntu Linux, in Terminal mode, using emacs, runs like a bat out of hell! I was able to recreate the script in about ten minutes that took me at least an hour to do at work. Some of this is because I had to remember how to write csh scripts again, and remember how to use sed to extract just some of the information out of wc -l, but also, Unix/Linux is still a spectacular development environment for basic software development, once you get vile out of the way.
Of course, I am blogging from the Linux box!
Of course, I am blogging from the Linux box!
Friday, October 1, 2010
MyEclipse 5.5.1 Experts?
Ctrl-Shift-G when you have selected a method searches for all references to that method. It appears to be smart enough that it isn't just doing a string search through the Java source; it only references references to that method associated with that class. This is a very valuable tool.
Unfortunately, it has suddenly stopped searching through Java classes--now it is only searching through JSPs. I did a Clean on my project, thinking it might be an index problem. Any other suggestions?
Unfortunately, it has suddenly stopped searching through Java classes--now it is only searching through JSPs. I did a Clean on my project, thinking it might be an index problem. Any other suggestions?
Sunday, September 26, 2010
JUnit
I have been a big fan of both automated system regression test and unit regression test for many decades. (It's a bad sign of how long you have been doing something that you can start to say something about your experience and say, "many decades.")
My last consulting job involved writing many hundreds of unit tests in Visual Studio/C# for a point of sale product. At my current job, the back end part of the software in written in Java and SQL. While there were some unit tests in the code, they had not been run or maintained for a very long time--perhaps for a number of years.
While waiting for others to make changes were blocking me from fixing stuff, I started looking at the existing unit test facilities. It uses JUnit--and My Eclipse has a very nice interface to it, almost as nice as the unit test facilities built into Visual Studio. In no time at all, I found the permissions problem that prevented the existing unit tests from running (most of which are now years of date), and fixed it.
In addition, one of the classes that I expect to change as soon as the DBA finishes his work needed a unit test. It also needed a more elegant and robust interface to the SQL. Let me explain, for those of you who have not had occasion to write code that interfaces to SQL. In both C# and Java, there are libraries that interface to SQL stored procedures. You call a method that executes a SQL command or stored procedure, and get back a series of returned rows. There are two different method categories for retrieving individual columns from a row, so that you can store them into a class instance. One category, which much of the current code that I am maintaining uses, retrieves each column by column number:
lastname = data.getString(2);
firstname = data.getString(3);
custNbr = data.getInt(4);
However, this is not a very robust technique. What is someone changes the stored procedure, so that the last name column is no longer the second column returned, but the third or the fourth column?
Instead, it is safer to retrieve based on the column name, not the number:
lastname = data.getString("last_name");
firstname = data.getString("first_name");
custNbr = data.getInt("cust_number");
The column name that the stored procedure assigns is what the various get methods use to retrieve the data for this column from this row.
Now, if the stored procedure does not assign a name to a particular column, retrieving by column number may be the only way to get the data--and some people who write stored procedures do not bother to assign a name to a column, even though it is dead simple to do so. I am starting to change such stored procedures to assign names, for this obvious reason. However, I wanted to make sure that my changes did not break anything, so I wrote a series of tests to verify that the data retrieval methods in this class returned the right data. This way, when we start changing the table structure, and when I check in the changes to the stored procedure, I can painlessly verify that these data retrieval methods actually work the way that they used to work.
In addition, while writing these method tests, I found a couple of exception cases that did not return the correct data--so one more set of things to fix, and make sure that they will not come and bite us in the future.
Days like Friday are the days that I actually enjoy my job.
My last consulting job involved writing many hundreds of unit tests in Visual Studio/C# for a point of sale product. At my current job, the back end part of the software in written in Java and SQL. While there were some unit tests in the code, they had not been run or maintained for a very long time--perhaps for a number of years.
While waiting for others to make changes were blocking me from fixing stuff, I started looking at the existing unit test facilities. It uses JUnit--and My Eclipse has a very nice interface to it, almost as nice as the unit test facilities built into Visual Studio. In no time at all, I found the permissions problem that prevented the existing unit tests from running (most of which are now years of date), and fixed it.
In addition, one of the classes that I expect to change as soon as the DBA finishes his work needed a unit test. It also needed a more elegant and robust interface to the SQL. Let me explain, for those of you who have not had occasion to write code that interfaces to SQL. In both C# and Java, there are libraries that interface to SQL stored procedures. You call a method that executes a SQL command or stored procedure, and get back a series of returned rows. There are two different method categories for retrieving individual columns from a row, so that you can store them into a class instance. One category, which much of the current code that I am maintaining uses, retrieves each column by column number:
lastname = data.getString(2);
firstname = data.getString(3);
custNbr = data.getInt(4);
However, this is not a very robust technique. What is someone changes the stored procedure, so that the last name column is no longer the second column returned, but the third or the fourth column?
Instead, it is safer to retrieve based on the column name, not the number:
lastname = data.getString("last_name");
firstname = data.getString("first_name");
custNbr = data.getInt("cust_number");
The column name that the stored procedure assigns is what the various get methods use to retrieve the data for this column from this row.
Now, if the stored procedure does not assign a name to a particular column, retrieving by column number may be the only way to get the data--and some people who write stored procedures do not bother to assign a name to a column, even though it is dead simple to do so. I am starting to change such stored procedures to assign names, for this obvious reason. However, I wanted to make sure that my changes did not break anything, so I wrote a series of tests to verify that the data retrieval methods in this class returned the right data. This way, when we start changing the table structure, and when I check in the changes to the stored procedure, I can painlessly verify that these data retrieval methods actually work the way that they used to work.
In addition, while writing these method tests, I found a couple of exception cases that did not return the correct data--so one more set of things to fix, and make sure that they will not come and bite us in the future.
Days like Friday are the days that I actually enjoy my job.
Subscribe to:
Posts (Atom)