Sunday, August 21, 2016

Have you ever had a great idea and pitched it only to have it ill received? Then later you found out that your idea is being implemented and the credit has gone to someone else?

This probably raised frustration or even anger within you. Perhaps they stole your idea and in their ego-centric ways decided to steal all the glory for themselves. How could they?!

Or perhaps there is another side to this.

Recently I brought up the idea to the my team that perhaps we should consider setting our focus to certifications, but not programmer certs but rather system certs... you know.. Security+, Network+, Oracle Administrator, that type of thing. Our core application is a Java application that is hosted on Solaris servers. Our contract has strict requirements for any one that touches those systems.

My pitch went something like this:

Me: "Hey, now that our development efforts are winding down and much of the work load is on the SA and DBA side what do you all think about considering system admin certifications?. It would help us with our knowledge and it would also make us more valuable to the project.".

There were a few other good reasons that I mentioned, but rather not go into all those details.

Two of the members quickly responded positively to it.

"Certs? We don't need no stinkin' certs!"

One of the two members pointed out that he had pitched the idea of certs a few weeks prior and we turned the idea down.

That conversation went something like this.

Me: "What do you all think we should consider for our next set of lunch and learn sessions?"Team member 2: "Maybe we should target certifications?"Me: "Ooh... I don't know I'm not crazy about anymore certifications. I'm not sure there is enough return on investment". This was in the context of the countless hours we spent previously prepping for the Java 7 certification. I assumed he was referring to Java 8 or Java 9 certifications.Team member 3: "No... I don't really want to do certifications either."Team member 2: "OK... it was just a suggestion...but never mind"

So when he reminded me about that conversation, it hit me. He gave up too quickly. He didn't elaborate on his idea. His idea was good but he did very little to sell it. I had long forgotten his pitch. Perhaps I stole the idea without realizing it.

"Features Tell. Benefits Sell!"

A good friend of mine and former Sears hardware salesman, once told me me "Just remember Fernando, features tell, benefits sell". I've never been a professional salesman in my adult life, but that phrase has stuck with me for about 16 years.

My team member didn't elaborate on the benefits. He didn't pitch his idea. In our minds we hadn't the slightest idea at the time why any certifications would be a good idea. A programming certification is almost meaningless (in many developer circles). Endless hours of studying only to be tested on obscure and mundane ways of programming that no one would never use in the real world. On top of that there are many good test takers that have those certifications but are not such great programmers. Sure, you gain some valuable knowledge along the way, but for all the minute and obscure nuances that you must memorize, it is hardly worth it.

A certification as requirement to actually do your job is totally different, specially when it's a topic that you should know but are weak in.

It's a requirement and regardless of your knowledge you are not getting on the system. That's a pretty good reason to get it. The idea also that, since security is becoming such an important concept, relative to software development, much of that knowledge will be very useful for us developers.

Perhaps I should have seen how good an idea it was when he pitched it. Or maybe, at least I should have provide a fair opportunity and followed it with "tell me more". But... I didn't. I got trapped in my own little world of immediate priorities and failed to see the bigger picture. I am human.

So we as programmers, techies whatever you want to call us, have products to sell. Our products are ideas. We must be prepared to make our pitch and be able to persuade. Not persuade for the sake of persuading, or persuade to get accolades, but persuade because we believe our idea is a good one.

We know our idea is good, so we must be prepared to lay it on the table for closer scrutiny, and demonstrate it.

And if our idea doesn't stand the test of scrutiny, at least we can say that we contributed responsibly. We collectively discovered whether the idea was good or bad. But at leas we considered it closely. But if our idea is really good... well... we all win.

SELL! SELL! SELL!

So always remember that your ideas are your product and no one knows your product like you do.

Thursday, July 28, 2016

If you’ve been writing code for more than a year, you might have heard of design patterns. I’m always surprised while interviewing veteran developers that have not heard about design patterns. I always make design patterns a topic during interviews because I believe they are a concept that every developer with more than a year experience should at least be aware about.

So when the interviewees response is “I may have heard of them, can you tell me more…”, I become quite surprised. In truth I’m no longer surprised as much anymore because I’ve come to realize that the developer universe is vast and many developers work in these little vacuums with very particular tools to get their job done without ever tracking the on goings of the bigger developer community. Is that acceptable for a developer, is it not? It depends.It depends if the developer wants to be more marketable or not. It depends if the developer wants to do better at interviews when the time comes for a new job hunt.

The idea that design patterns are necessary is debatable. Some argue that the only reason we need design patterns is due something lacking in the given programming language. Others live by and love them. In my 15 years of experience I can say that the knowledge of design patterns is important for a few reasons.

Thursday, June 30, 2016

For every programmer out there creating brand new code and working on the latest technology, there are many of us who are cutting our way through the code maintenance jungle.

Maintaining code is not for everyone. Some programmers love creating brand new code and introducing new technologies. We need those programmers in order to move companies and coding technologies forward. At the same time all projects eventually require maintenance. That’s where we need programmers that will do the dirty work of maintaining code and if they love it it’s even better.

Maintenance can mean a lot of different things. Maintenance can sometimes mean fixing defects. Other times it can mean enhancements. Sometimes it can mean refactoring and paying off technical debt. Or as in my latest case modifying the code to meet new technical requirements. Maintenance is not totally exclusive from creating brand new code. Maintenance sometimes means moving from the old to the new.

The Problem

In my latest case we are faced with a challenge of replacing a Java Applet with HTML and JavaScript. The Applet in question was put in place many years long before I came on board in the project, probably when Applets were still and adequate approach for rich controls web applications. For the last year or so the applet has becoming quite a hassle to deal with. The applet itself requires no changes, it works as designed. However, applets are a high security vulnerability. One of the first things we had to do was have the applet signed (it was a really painful and non-straightforward process). It required a signature because it would stop running with each Java update. Moving forward, as of January of this year Oracle has announced its plans to remove the Java plug-in for browsers. Its decision is based mostly on the fact that browser vendors have announced their timeline for dropping support for plug ins.

Sunday, May 15, 2016

Recently I ran into a great offer that I just couldn't pass up. I have been in need of screen capture software for creating online tutorials. I've heard that Screen Flow is an awesome product and quite inexpensive. Unfortunately I switched from Mac to a Windows 10 box and Screen Flow is only made for Mac OS. My best alternative for a long time has been CamTasia Studio.

I was reluctant to get CamTasia because $300 is simply too high a price. So... recently I ran into this other product called Movavi which costs only a fraction of what CamTasia costs (as of this writing it costs 59.95 which includes 40% discount). I downloaded the trial version and did a quick demo to test it out. It worked like a charm. The trial version is limited to two minute videos.

I proceeded to purchase the next day because finally I would have the software to create online tutorials. I was not ready for the big disappointment that was lurking in the shadows. I did my first video with activated software, which was a 15 minute video only to find out that it stopped capturing the screen after about a minute and a half.

At first I thought maybe it was because I was switching applications during my tutorial so I tried with only one application later and got the same results. I tried a few settings and got the same results.

By this time I was a little frustrated and proceeded to contact Movavi's tech support. The tech recommended that I try un-checking the acceleration. With the tech on the line I did a recording and it seemed to work.

I came back to giving it another try this Saturday excited that I would finally be able to record my tutorial but once again on a longer video the software failed to capture after about the minute and a half mark.

At this point many thoughts ran through my mind. I was extremely frustrated and the worst of it all was that I might have to purchase Camtasia after all. Thought's like "What a POS software this is" came through my mind but my mind at the same time challenged me to be more calm about this and think of how great this software is when it actually works. It challenged me to think of all the work that the producers of this software put into it.

After all, I am a software developer too and sometimes things go wrong that cause great frustration. Many times the cause is due to external factors such as a JDK update or server patch that breaks things. It's not that we didn't take pride or were apathetic to the quality of our product. That is simply the nature of software. Human error will creep in at some point or another. So that little voice in my head said keep cool maybe there is still a way to get it to work.

Then I remembered those little words that the tech said on our last conversation " and just keep in mind that if you have any other issues check the box that says Use Alternative Rendering..".

That was exactly what I needed to do. I checked that setting and now Movavi works like a charm. What a great piece of software it is, indeed. Even if the software had not worked for me it could be to weird hardware compatibility problem and with so many possible PC configurations that is extremely challenging.

Moral of the story is stay cool when the software you use doesn't quite work. Maybe it does work after all, it just needs a few adjustments.

Friday, May 6, 2016

As a friend and I were walking through the Barnes and Noble Technology section today, he asked me "I want your opinion on what you would do to learn one of these programming languages today". My response was "I would buy me a subscription to PluralSight.com and get serious about learning from there".

Let's face it. You have many options today to learn something new. If you have a computer and an internet connection you learn just about anything. You can learn most of what you need to know from the internet and yes the internet has a lot of your answers and you can learn it for free. The problem is that you get what you pay for. You may actually pay more for something that is free because although the monetary cost is zero you end up paying with your time. That's the caveat on learning anything for free, you may just spend a lot more time than necessary trying to be cheap.

That is why my top choice for learning programming today is PluralSight.com. There are many options such as Udemy and Khan Academy, Lynda.com etc. For programming I would definitely pick PluralSight. PluralSight has simply had the best quality of all the videos I have seen.

Udemy is a good option and has a good format, however the problem is that sometimes you might end up with a crappy lecture and find out only after you've already paid for it. I like the idea of owning the video for life but if it's not worth it, why would you want it for five minutes. With PluralSIght on the other hand you can abandon the video and move to a different one if you don't like it and you stay pay the same monthly price. PluralSight is $30/month and you can watch as much as you like.

Books can be a good option but I would reserve buying books for things not offered online or for full references not otherwise available. When I started my career we had a few options of learning things online but for the most part the real answers were buried in books written by experts. Today things have changed.

Most of what the experts know can be found online. However, the drawback is that online information is not neatly organized so sometimes you may need that Expert Programming book. However, I have found that learning from video tutorials is much more natural for the learning process. Reading a novel is one thing. There is a natural flow of engagement, but reading technical books takes a lot more brain cell processing. Technical documents tend to trigger other thoughts and ideas which interrupt the natural flow of learning. I've always found it more natural to watch a video than to read a book. Maybe that's not the case for everyone but it may be for many people like me. So I would reserve using a book only if I couldn't otherwise get the information.

Also it seems that I can finish a video tutorial on a particular technology, including, hands on within a couple of weeks whereas it takes me many more weeks to actually read and understand the same thing from a technical book Many times it's hard to even get through the book.

Friday, April 29, 2016

For the last two months or so my fellow McLane Advanced Technologies Programmers and I decided to take on Python. We all have pluralsight accounts so we decided to engage in the Python Fundamentals course by Bingham and Smallshire. It took us a couple of months to get through the course since we only would do it through our lunch hour. With schedule conflicts, practice exercises it took us a while to get through the course but we finally completed it a couple of weeks ago. And I must say, it was an amazing course. The crazy part about the course is that it's only 5 hours long. Five hours plus another 10 hours of hands on practice and you can be pretty decent at python.

Throughout the course we took time on our own to do some exercises after each of the lessons. I fiddled around with it quite a bit and decided to save my practice exercises to github.com (https://github.com/fernandozamoraj/py_sandbox).
Although our goal is to go deeper with the sequel to this course, Python Beyond the Basics by Bingham and Smallshire, I want to list a few important lessons about python.

Python has a term called "Pythonic" to indicate the Python Way

Python is easy to learn. Any seasoned programmer can come to Python and learn it well enough in a matter of hours. However, Pythons capabilities and syntax call for a certain way of doing things. What I mean by that is the way you do something in one language, although it can be, should not necessarily be directly translated into python. This concept differentiates the hacker or beginner from the fluent programmer. One example that comes to mind is the typical swap of values like one does in sort routine. For example.
In most languages (Java, C#, etc) you do a swap like this:

This is possible in python due to tuple inference. Python automatically treats these type of assignments as tuples. So it takes the first value on the right of the equals sign and assigns to the first variable on the left side of the equals sign. It does this also for the second variable and value.
While you can translate how it's done other languages directly to Python, it would be considered unPythonic.
You can learn more about the term Pythonic at http://blog.startifact.com/posts/older/what-is-pythonic.html. There is also a good video on youtube about becoming "fluent" in the Python language at https://youtu.be/E88m_uQxt1g.
Python has many capabilities that other languages don't have and therefore you shouldn't necessarily translate how you do one thing in another language to Python. Some of these features at the root cause are:

I've never seen any such thing in other languages. In other languages the guidelines are usually de facto standards but they are not necessarily written anywhere by a solid authority. In Python they are in black and white at https://www.python.org/dev/peps/pep-0008/. These guidelines provide an easy reference for all Python programmers to share.

This has several advantages. One being that they can be readily adapted by any programmer team. Also, since they are widely accepted it helps all Python programmers to read each others code.

The Zen of Python aka PEP 20. Again I have never seen this in other programming languages. Although some widely accepted principles do exist such as SOLID.

Python Is Dynamic

Python is a dynamic language which brings along the advantages and disadvantages of a dynamic language. Those advantages will force the developer coming from a static language to think and code differently. A programmer must also take certain precautions in order to overcome redefinition of methods and attributes. This can lead to some frustration for the static language programmer in finding obscure run-time bugs.
This means unit testing much more important at least from the perspective of exercising your code. Unit testing is important period, but in the case of Python an un-exercised path might give a nasty run-time surprise. For example, you may discover that type has not been initialized before being used or that a method does not exist. These types of errors are caught the compiler, in a static language, but only until run-time in python. A simple typo would look fine until run time.

Classes in Python Are Totally Different than .Net/Java

Python's classes make every attribute and method public, period. Not by default, just period. There is no protected, private and public accessors. Python's guidelines indicate that you should code your fields a certain way if you intend them to be "private". For instance the field/attribute _first_name in the class Student would be considered private, because it starts with an underscore, and not be modified by external access. So in essence encapsulation in Python is a guideline not a rule.

All of a classes methods are static
Take the following code for example

You would think that the second example is using a static method and the first is using the instance method. In fact they are both using the static version. However the one that appears to be instance is only syntactic sugar and is actually doing what the second approach is doing behind the scenes.
Another point to notice is the "self" variable. Coming from another language you might think that the word self has special meaning, and it does but only by convention. There is no "this" in Python classes. Self is not equivalent to "this" in that regard. It does represent the object in a sense but it could be named anything else. That is why it is always passed to "instance methods". If it is not passed the class cannot see it, unlike traditional Object Oriented classes, self is not available unless it is passed in to the function/method that needs it.

Take the following code for example;

s = Student()
s.log()
s.foo()

In the above code s.log will work, but what will it print? It will print the s (Student) object. The calls
that is essentially made is

Student.log(s)

So you see, "self' has no special meaning.
The second call s.foo() will result in a run time exception because the call that will be made is Student.foo(s), passing s as the first parameter but Sudent.foo does not accept any parameters.

Inheritance

Inheritance is another big one. In Python inheritance is usually use for re-using code but not for its polymorphic capability. Take the following example:

The above code is an example of duck typing, something very common in dynamic languages. Since the call foo call is not resolved until run time, it can work on two different types as long as they implement that interface.
More differences exist in classes between Python other classy languages but these are the ones that really stand out.
I've noticed quite a few differences regarding the nuances of Python. Many of the nuanses can be explained in detail in other posts or even in the Python online documentation. My intent with this post it to show those C#/Java programmers with a curiosity about Python, some significant differences that are not readily apparent.