Tuesday, December 13, 2016 #

First Go Lesson: Variable declaration and passing by reference

I beginning my journey with Go by taking the Go Fundamentals Pluralsight course. It’s great so far.

I would love to share some interesting stuff I see about the Go language. Also, it helps me not to forget the nuances of the language and reassures me that I understand how things work.

Variable declaration

Declaring variables in Go is quite interesting. The var keyword is only used to declare variables that are package scoped. Package scope means that the variable can be used by any function inside the package (think module in Node world or namespace in C#). I’ve never really thought of that kind of scoping before. I’ll have to dig into that more as I continue to learn.

The interesting thing is that if you are declaring and instantiating a variable in Go inside a function, you use the “:=” syntax (colon and equals) like this:

variable-assignment

Also, I find it interesting that Go will not compile if you declare a variable and not use it. That is a great way of making sure there is no waste in your programs.

Passing parameters by reference

Go has another interesting “feature”. It always passes function parameters by value. This means that a copy of the value is created and then passed in. Any changes made to the value of that parameter while inside the function will not change the original. So if you declare a variable in one function, pass it into another function that manipulates the value, then use that value after the second function is called, you will get the original value. Let’s say the code looks like this:

func_pass_parameter

The output when this code is run is the following:

Go_not_reference

Notice how the course name does not change. I’m used to languages like C# where whether or not a parameter is passed by value is dependent on the type of the variable. For instance, strings are always passed by reference and ints are always passed by value. Here in this example, we see that even strings are always copied when passed into functions in Go. You have to use pointers in Go if you want to pass by reference and change the original variable. Notice the changes in the following code:

Refrerences

Now when you run the code…

reference_output

The original value is changed. Cool stuff.

If you are interested in learning more, please check out Nigel Poulton’s Pluralsight course: Go Fundamentals. These code samples came from his course. It’s great.

Posted On Tuesday, December 13, 2016 12:00 PM | Comments (0)

Monday, December 12, 2016 #

I’m back after a long hiatus

It’s been some time since I’ve written to this blog. I guess life got in the way and at the time I didn’t feel that I was contributing enough to warrant the time taken to write up my articles. However, I have received views and comments on the blog complementing my writing style and encouraging me to keep writing.

Another factor is the fact that I have recently come back to read my old posts and actually liked what I read. I felt that I actually did have something to contribute, even if at the time I wasn’t convinced my pontificating would go very far.

At the very least, it is somewhat therapeutic to write these things down. I’ve learned so much in the past 5 years since I posted anything here and I feel that there is more to share. Not only that, but sometimes blogs become a great place to put stuff down that you don’t want to forget.

I don’t want to forget my initial thrust for this blog. It is called the Green Machine because I hoped I could use it to show that young and inexperienced developers do have something to give and can make great software. I was a young and inexperienced developer myself when I started it. Of course, I’m old and grizzled now Smile but I still have something to tell these young developers.

 

The truth is, we are all young developers in some capacity. I consider myself an accomplished C# and JavaScript developer. I now am embarking on a journey to learn Go. In terms of Go, I am a young and inexperienced programmer. Maybe that is a great upside of the software world. At any time, you can choose to reinvent yourself by learning a new language and trying to see where it can take you.

I’ll post my findings when it comes to learning Go. I hope you’ll find it as interesting as I do. I’ve also started the journey into application security, gaining my CompTIA Security+ certification. Be on the lookout for blog posts on security as well.

 

Hopefully, there will be some out there willing to bear my pontificating once more Open-mouthed smile

Posted On Monday, December 12, 2016 10:03 PM | Comments (1)

Thursday, December 22, 2011 #

Advice for Young Developers: Learn to Make Your Own Decisions

Everyone has an opinion. When you embark upon your first real job as a programmer you will find this out very quickly. I have found that software developers can be some of the most opinionated and dogmatic people you will ever meet. This certainly is not a bad thing. However, young programmers will need to cultivate the ability to make their own minds up when it comes to how to write software.

There are those who start out in a corporate environment where the styles and conventions used have already been established. There is not much you can do usually in this situation, at least not right away. I am speaking to those who may have a say in how things are built. Such a position usually requires that you do research on the best way to solve certain problems. You research design patterns, OO principles, etc. Everyone has an opinion on what the best way is this can cause confusion. The remedy is to simply make up your own mind. 

Whose side are you on, anyway?

It may be helpful to look at some examples of what I mean.

No view left code-behind – The MVVM debate

I have been using WPF and the MVVM pattern. There is the great debate as to whether there should be code in the View’s code-behind file. Many will dogmatically say no. Some will say yes. Others will say sometimes. Which side are you on? That is a decision that you have to make. As for me, I’m on the sometimes side. It’s important to me to remain balanced. An example is animations. To me, it’s seems silly to be so dogmatic that you create more unnecessary complexity just to keep code out of the code behind. In the code behind I can do this to fade in an element over 400ms:

someElement.BeginAnimation(opacityProperty, new DoubleAnimation(0,1, new Duration(TimeSpan.FromMilliseconds(400))));

Or I could implement a complex solution such as this. Neither is wrong in the right situation. A choice has to be made. I simply prefer the first choice in most scenarios.

Inter-face off – Too many interfaces?

Another example is the use of interfaces. I have heard countless times that proper OO design means always coding to an interface. Then you can switch out implementations without changing the client code. This is certainly a noble ideal. I started writing everything like this at first. Now I don’t create an interface for every single class that I need to use. Why? Because I read the other side of the story. The summary of the previous post is that it is pointless and a form of premature optimization (the author uses the term “speculative generality”) to create interfaces when you know that they will only have one implementation. Why create an ICustomer interface when you know that only the Customer class will implement it? The proper way to do it is to actively refactor your code. When you see two or more classes that use the same or similar methods and properties, then refactor to include the appropriate interface. Only create interfaces when there is a demonstrated need. Again this is an issue where you have to choose what you think is the best solution.

Yeah, but what does this mean to me?

Opinions are everywhere. It’s easy to get lost in them. Just remember these important points and you will be fine:

1. Don’t take your code too seriously. Chances are, your code is not as good as you think it is. There is always a better way to do it and you rarely do it right the first time. So don’t obsess over the “right” way to do something. It doesn’t exist. And don’t be afraid to refactor when you do find a better solution.

2. Context is everything. Most solutions do not work in all situations. One of the most difficult parts of software development is learning the right thing to do in certain contexts. Just because you can do an Abstract Factory, doesn’t mean you should. You don’t have to avoid code-behind files like the plague. Don’t overuse them either. Everything is relative.

3. Remember why you’re there. You’re main purpose of being a software developer is to bring value to the business. That means not wasting the company’s time and money implementing unnecessarily complex solutions over simpler ones that work fine just because so-and-so said you should. Is he going to personally come and inspect your code? I doubt it. The business will be grateful for well-designed solutions that don’t take forever to build, and it’s the business’ opinion that you should care about.

It doesn't matter what decision you make, only that you make an educated one. Listen to both sides of every story and then listen to your gut.

Posted On Thursday, December 22, 2011 9:25 PM | Comments (8)

Sunday, December 11, 2011 #

Are Young Programmers Missing Out on the Fun of Programming?

I read two blog posts recently that got me to thinking. The first is a post entitled Programming Isn't Fun Anymore by Eric Allman. The second is a response to the first by Dean Wampler called Programming can be fun again. These brought the question to my mind as to whether or not new and young programmers are missing out on some of the fun parts of programming.

 

Eric’s post explains that some older programmers are realizing that most development work (especially in the OOP world) involves learning and stitching together tools and frameworks in order to support the smallest bits of programs. He laments that older programmers use to program algorithms in order to get their jobs done. Now, you learn libraries that implement those algorithms for you and you don’t really have to know how they work in order to just link them all up and make a program work. I think that he may have a point, and any new programmer can certainly understand.

 

Most college programs start teaching programming with languages like Java, VB, and C#. Some, like Stanford or MIT CS courses may make you take C and LISP courses, but many other colleges don’t bother with these much. I personally started with Java and then moved to .NET. I never learned C, C++, or any functional languages in school. So the question comes up: If we are starting with libraries that write algorithms for us to the point that we don’t really need to think about them, are we missing out on a fundamental part of programming? I tend to think so.

 

I feel that I understand much more now about programming than I did coming out of college. This may seem like no surprise but I have worked hard learning everything on my own. It has taken considerable effort to learn what I have. It could be all too easy for someone to continue just connecting up this framework with this library and somehow it all works. Older programmers have a different perspective on how bloated these kinds of tools ultimately become. Then what inevitably happens is we become dependent upon these tools in order to do any programming. Is this really beneficial or desirable? I tend to think not.

 

I recently took some time to really learn some basic algorithms and data structures. I am still learning but I can say that I have implemented a linked list, which then I used to build a stack, a queue, and a priority queue. I have also implemented a binary tree as well as a hash table just so I understand how they work internally. Sure, there is a stack, a queue, a dictionary, etc in the .NET libraries, but I’ve always been uncomfortable using something that I do not fully understand. That is where the disconnect occurs between older programmers having to implement these algorithms themselves and just using a library. With a library you are always running the risk of using something which you do not understand fully. This can also contribute to creating programs that grow into bloated messes even though they are following a pure OO methodology. All this because one simply does not know any other way.

 

This brings me to the second post. Dean mentions that functional languages are making programming fun again because of their concise and elegant syntax that is also very powerful due to its declarative nature. You can do more with less code without the bloat of libraries and frameworks. This is an interesting way of looking at things. I can certainly understand now that I have learned some Ruby and realize how nice it is since it borrows heavily from functional languages.

 

With this in mind, I have decided to take a good long look at functional languages starting with F# since I am already comfortable with the .NET framework. I also would like to explore scala, clojure, and maybe even scheme or some other lisp. It’s this kind of discussion and exploration that makes programming fun for me. So even if you are new to programming, there are ways to keep things interesting and fun.

 

My advice to young or new programmers: Step outside of your comfort zone. If you are primarily an OOP developer, then try functional languages. It’ll help you think differently and you will probably have some fun along the way.

Posted On Sunday, December 11, 2011 12:52 AM | Comments (0)

Tuesday, November 8, 2011 #

Was I wrong about JavaScript?

 

Yes, I was. Recently, I’ve taken a good hard look at JavaScript. I’ve used it before but mostly in the capacity of web design. Using JQuery to make your web page do cool stuff is different than really creating a JavaScript application using all of the language constructs. What I’m finding as I use it more is that I may have been wrong about my assumptions about it. Let me explain.

 

I enjoyed doing cool stuff with JQuery but the limited experience with JavaScript as a language coupled with the bad things that I heard about it led me to not have any real interest in it. However, JavaScript is ubiquitous on the web and if I want to do any web development, which I do, I need to learn it. So here I am, diving deep into the language with the help of the JavaScript Fundamentals training course at Pluralsight (great training for a low price) and the JavaScript: The Good Parts book by Douglas Crockford.

 

Now, there are certainly parts of JavaScript that are bad. I think these are well known by any developer that uses it. The parts that I feel are especially egregious are the following:

  • The global object
  • null vs. undefined
  • truthy and falsy
  • limited (nearly nonexistent) scoping
  • ‘==’ and ‘===’ (I just don’t get the reason for coercion)

 

However, what I am finding hiding under the covers of the bad things is a good language. I am finding that I am legitimately enjoying JavaScript. This I was not expecting. I’m not going to go into a huge dissertation on what I like about it, but some things include:

  • Object literal notation
  • dynamic typing
  • functional style (JavaScript: The Good Parts describes it as LISP in C clothing)
  • JSON (better than XML)

There are parts of JavaScript that seem strange to OOP developers like myself. However, just because it is different or seems strange does not mean it is bad. Some differences are quite interesting and useful.

 

I feel that it is important for developers to challenge their assumptions and also to be able to admit when they are wrong on a topic. Many different situations can arise that lead to this, such as choosing the wrong technology for a problem’s solution, misunderstanding the requirements, etc. I decided to challenge my assumptions about JavaScript instead of moving straight into CoffeeScript or Dart. After exploring it, I find that I am beginning to enjoy it the more I use it. As long as there are those like Crockford to help guide me in the right way to code in JavaScript, I can create elegant and efficient solutions to problems and add another ‘arrow’ to the ‘quiver’, so to speak. I do still intend to learn CoffeeScript to see what the hub-bub is about, but now I no longer have to be afraid of JavaScript as a legitimate programming language.

 

Has something similar ever happened to you? Tell me about it in the comments below.

Posted On Tuesday, November 8, 2011 9:45 PM | Comments (4)

Thursday, October 13, 2011 #

Beginning My Journey with Ruby

I recently began feeling like it was time for a change. I have been programming in C# for about a year and so I felt the urge to learn something new. So I went to the library and checked out a book on Ruby programming. I chose Programming Ruby 1.9 written by Dave Thomas and part of The Pragmatic Programmers series. I figured I might as well document my journey into the new world of Ruby on my blog.

I’ve gotten through about six chapters and I really like what I see from Ruby. It’s really fun to learn and play around with. Here are some of the parts that I like so far or that I find interesting:

 

Everything is an object

This is kind of weird to someone coming from the .NET world. However, this rule leads to some cool stuff. Let me explain. In .NET languages, there are value types and reference types. The CLR treats them differently. Value types are instantiated and allocated on the stack and these include the basic types such as int and double as well as structs such as DateTime. Reference types, such as strings and any instantiated object, are allocated on the heap, which requires more overhead and also requires garbage collection. In Ruby, there are only objects, no value types. This may contribute to the fact that Ruby can be slow compared to other languages but I’m not sure. Either way, I think it’s nice because it allows for objects to be self-contained and to control how they are manipulated. Take for example parsing a string into an int in C#:

string example = "25";

int intExample = Int32.Parse(example);

 

Now look at the same operation in Ruby:

example = “25”

int_example = example.to_i

It’s a simple example, but it illustrates what I’m talking about. In C# you have to call Int32’s static method Parse and pass in the string. In Ruby, you simply call the to_i method on the string and it turns itself into an int. It leads to easily understandable and succinct syntax that every programmer can appreciate. Another example, in Ruby you can do this:

1.to_s 

This returns the string “1”. 1 is not a constant like it would be in C#. This is also possible due to the dynamic typing of Ruby, but the number 1 here is an object of type Fixnum and I am calling the to_s method on the 1 object.

 

Cool shortcuts built into the language

Something I think is pretty cool just from a syntactical point of view is the bevy of shortcuts built into the Ruby language. One example is the shortcut provided for getters and setters inside of classes. Here is an example:

class Shortcut
  attr_reader :x
  attr_writer :y
  attr_accessor :z

  def initialize(x, y, z)
    @x = x
    @y = y
    @z = z
  end

end

The attr_reader shortcut creates a getter but no setter for the x variable. The attr_writer shortcut creates a setter and no getter for the y variable. And the attr_accessor writes a getter and setter for the z variable. That’s a lot of repetitive code that now can be skipped. Great idea. Especially when you think of how many times a day C# developers have to write getters and setters. Another nifty shortcut deals with arrays of strings. If you don’t feel like writing a bunch of quotes and commas you can simply write this:

myArray = %w[cat dog mouse house car]

This returns a string array and inserts the necessary punctuation for you. Another nice time saver. There are many more little gems like this that just make writing Ruby a little easier.

Well, that’s all I’ll write for this post. I hope you enjoyed it. I still haven’t scratched the surface of all the great stuff you can do in Ruby. As I learn more neat stuff about Ruby I will share my thoughts here. Thanks for reading and have a great day!

 

Posted On Thursday, October 13, 2011 1:18 AM | Comments (4)

Thursday, September 22, 2011 #

Be Balanced When Deciding on Application Architecture

Something that took me a while to learn is how to be balanced when deciding on how to architect an application. Since at my current job I was thrown into a hybrid Architect/Developer position due to the small size of the company and my team, I didn’t really have any experience with doing it. After almost a year at it I decided to look back and see what I have done and how I can learn from mistakes and successes.

Remember Why You Were Hired

Why did your company hire you as a developer? If you answered “To create great software for employees and clients to use” you are wrong. You get hired at a company in order to create value for them. In the end, any software that you create needs to have a solid ROI, whether it is used by employees or clients. Does this mean that you should throw together whatever crappy code you want until it just works so that you can do it as quickly as possible? No, good architecture requires you to take maintainability into account as well since the business’ money will also be used to maintain the code (actually, more will be spent on maintaining than building). The problem comes in when a developer wants to solve a problem with a solution that is more complex than it needs to be and the extra time that it takes to implement that solution is really money wasted for the business. I’ll look into this in detail throughout this post.

The Folly of Anticipating Change

In the world of software, change is inevitable. With this in mind, developers naturally design systems so that they are adaptable and easy to change. However, there is a difference between creating a system that is easy to change and developing a system that anticipates change. If you try to anticipate changes before they come, you are wasting your time and, more importantly, the company’s time. You don’t know what changes will come down the line and if you anticipate a change that doesn’t happen then you will end up over-engineering the solution and causing a huge headache down the road. Focus on what is needed now while building an infrastructure that can change with as little effort as possible (such as using dependency injection and programming to interfaces). Rather than trying to build a system that will never have to change, build a system that embraces change and expects it. In the end, it’s really not that hard to change software, that’s why it’s called soft-ware. So stop worrying so much about what will come down the road and concentrate on the requirements right in front of you.

Design Patterns = Complexity

A final point on this subject (for now, at least) is that it is important to remember the cost of design patterns. Design patterns are great when they are applicable but they don’t need to be the first place you go to in order to solve every problem. This is because design patterns by their very nature add complexity to your application. This complexity is not always necessary. Be careful not to over-engineer your application just to use a design-pattern you want to try out. Every situation is unique; the word “pattern” implies a situation that repeats. Therefore, you may have to come up with a unique solution that fits the problem at hand. It is possible to architect a well-designed, elegant solution using object-oriented principles without having to adhere to a strict, named pattern. When a problem or situation arises and a design pattern fits the bill, then by all means use it. Just be mindful of the consequences of using it and make an informed decision.

All in all, the moral is to use balance. Remember that you are ultimately at your job to create value for the business, not build a beautiful piece of art to show off. Do you care that the pipes in your house are works of art or that water runs when you turn the knob? Build your applications so that they embrace change, not anticipate change. And don’t over-engineer your application for a design pattern’s sake. Use them only when you really need to. These principles help to provide well-designed, maintainable solutions that will bring value to your business.

Posted On Thursday, September 22, 2011 9:33 PM | Comments (3)

Wednesday, September 7, 2011 #

5 Reasons Why Unit Testing is fun–and Important

Yeah, you read that right. I may be weird, but I do think that unit testing is fun. It is also very important. I didn’t know much about Unit testing when I came out of school. I think colleges need to have a class dedicated to it. But anyway, I didn’t do much of it at my previous job since I was developing the Siebel CRM. Since Siebel is an Oracle product, it involves mostly configuration and customization using built components. We did some integration testing by building any new components into a local copy and making sure it worked against a local db before checking in any changes but that was it. Now, at my new position, I find myself being the major proponent of unit testing. The other developer on my team is fresh out of college practically and as with me the art of unit testing is lost on him.

I took it upon myself to introduce and spearhead the unit testing effort for our current project. What I have found is the more that I write unit tests, the more I like it. As the title mentions, I’m starting to have fun with it. Every new programmer needs to understand how to unit test their code, and these are the reasons why it’s worthwhile.

  1. Instant Gratification: Unit testing allows you to execute your code right away and know that it works. This is a very powerful tool. One of the reasons I enjoy programming is seeing the results of what I built. Unit testing allows you to instantly try out your code and see it working.
  2. Code Against Your API While or Before it is Built: Unit testing gives you the chance to code against your API/class while you build it, or in the case of TDD, before you build it. Your tests then become a template for future classes that use the API. They will interact with it the same way that a client class will.
  3. Leads to a Better Design: Since unit testing should start very early in the process of writing code, it can help you to design an API. Since the tests will become templates as to how to use the class under test, you can get a feel for how natural the API feels. This ultimately leads to a better design and helps you to choose good names for methods and also to determine which methods are really needed.
  4. Understand How Your Code Works: Unit tests really work out your code and tell you how your code will act under many different scenarios. Whether the tests pass or fail, you will learn something about how your code executes.
  5. Confidence in Your Code: You may have heard the phrase “Refactor without fear” and unit testing gives you this capability. This means that you can make changes to your code and instantly know whether those changes have broken it. When you have a good baseline of tests, you know your code works and you don’t have to be afraid of changes to it in the future.

For any new programmers (or programmers new to unit testing), I highly recommend the book The Art of Unit Testing With Examples in .NET by Roy Osherove. You can find it on Amazon here. This is one of the only and arguably the best book about unit testing ever written. I cannot say enough about it and it is a must-read.

I hope this post has shown you why I have come to enjoy and champion unit testing in my current position and hope this moves some other young programmers to do the same.

Posted On Wednesday, September 7, 2011 12:22 AM | Comments (4)

Friday, September 2, 2011 #

Embrace Problems – They Will Lead You to Knowledge

 

If you are a developer, you will encounter countless problems in your career. As a developer, problem solving is what you do. Still, some may try to shy away from problems in order to make their lives easier. I say do not, especially if you are a new developer or are learning a new technology. Learn to embrace problems as they come along.

I am not simply referring to basic business problems, but issues that you encounter that cause weird problems that you must solve in order to continue. I’ll give you an example.

Today the other developer on my team asked me for some help. We are using Entity Framework (EF) for our custom ERP program. We had created a view in the database for a piece of our application and had added to our Entity Data Model (EDM). The other developer found that there were duplicates in the view query results and so changed the SQL to eliminate it. However, when he tried to refresh the view in the EDM, it didn’t work because it couldn’t infer an entity key (since views do not have primary keys).

After delving into the problem, we found that EF requires a non-binary, non-nullable field in order to infer an entity key. The old query had a column that was the result of a COUNT() function that EF was using as an entity key and we got rid of it. We ended up having to add the entity manually to the CSDL and the SSDL, assigning an entity key of our choosing.

While some problems can make you bang your head against a wall and frustrate you, understand that these kinds of issues ultimately increase your understanding of the underlying technology. I know much more about how EF works since I now had to create an entity from scratch in the XML, despite the natural want for it to “just work.” Next time this problem arises, I’ll know what to do. And I found it to actually be fun. Remember that knowledge is the treasure that you find when you keep digging to solve problems.

Posted On Friday, September 2, 2011 8:52 PM | Comments (0)

Build UIs the way you would want them to be built

A lesson I learned while building a module in the custom ERP I am working on at my job: build the UI the way you would want it to be built. What do I mean by this?

I’ll explain by sharing my experience. There was a piece of the application that had a textbox that the user used to enter a client number. They then click the Search button to bring back the results. When I launched the application to test it out, I found myself typing in the client number and hitting the Enter key. It kind of came naturally. The Command was not bound to the Enter key so nothing would happen. Also, the requirements did not say that the user will be able to use the Enter key to search. So what did I do?

I bound the command to the Enter key which is actually quite simple. Just add the following XAML to your view (a UserControl in my case):

 

   1:  <UserControl.InputBindings>   
   2:       <KeyBinding Key="Enter"   
   3:                   Command="{Binding SearchCommand}" />   
   4:  </UserControl.InputBindings>
   5:

Here is the moral of the story:

If an action feels natural to you, it will feel natural to your users. While you are building the application, your users will not immediately get to use it as much as you will. So when you notice that a feature just “makes sense” from a user experience standpoint, just do it. Your clients/users will appreciate the forethought.

Posted On Friday, September 2, 2011 8:45 PM | Comments (0)

Copyright © jboyer

Design by Bartosz Brzezinski

Design by Phil Haack Based On A Design By Bartosz Brzezinski