Author Archives: erik

The Technical Skills You Need to Have as a Software Developer

In this blog post, John Sonmez talks about “soft skills” and how they can help you become a better software developer. Here are some tips from the author:

1. Instead of trying to learn several programming languages at the same time it’s better to have one language that you know in and out, that you are comfortable writing.
2. Structure your code well by writing “good, clear, understandable code that doesn’t require a large amount of comments because the code itself is communicative.” – John Sonmez
3. Having a good understanding of object-oriented design and managing complexity as most popular languages rely heavily on object-oriented design and analysis.
4. Understanding how to create algorithms, and how to modify known algorithms to match your specific needs.
5. Understanding of data structures like arrays & vectors, linked-list, stacks, queues, trees, hashes and sets. These are important to know well, especially if you are being interviewed.
6. Knowing a development platform well is a good idea because some places design for specific platforms (PC, Mac, etc)
7. Learning a framework, or a complete stack. “A framework is simply a set of libraries that are used to develop code on a particular platform or on multiple platforms.” and “A stack is a set of technologies, usually including a framework, that are commonly used together to create a full application.”
8. Basic Database Knowledge, how to add, modify, delete and work with different database systems.
9. Source Control, understanding how to use tools like GIT.
10. Testing, more often projects are being created in small increments and tested as they go, this is allowing developers to catch bugs before they begin to cascade.

I chose this resource because I’m always looking for information on becoming a better software developer and want to become an asset to wherever I dedicate my work. Some of the information is general information but I do think it’s important to work on maintaining these core skills to improve the quality of your work. I learned the importance of working on knowing at least one language very well, along with knowing one platform very well knowing how to implement popular data structures, writing good algorithms and knowing when to use what. I learned the importance of object oriented design and how prevalent it is today. I learned about frameworks and stacks and what they are, and the importance of understanding how databases work. I also learned that more recently developers are being expected to know how to test their code, especially with agile testing.

The post The Technical Skills You Need to Have as a Software Developer appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

How to Work With Someone Else’s Code

In this blog post, Justin Albano gives advice on working on code written by others. It can be tough making changes or adding to code that you did not write yourself, another reason why clean code is so important, it helps other have a clear idea of what’s going on. The author notes pitfalls that you should watch out for when working with someone else’s code:

Our Ego: We think we know best, but must respect the code and original author.
The ego of the original author: Working on code written by someone else may lead to questioning decisions made by others which must be met with working with the original author.
Fear of the unknown: Many times you are going to be working on code that you know very little about and will be responsible for those changes. It’s important a framework is built to ensure changes can be made comfortably with no worry.

Some techniques for maintaining clean, functional code:

1. Ensure Tests Exist When current tests are not sufficient, you must create them yourself, which can be challenging. Other times, having tests provided for you, you can learn from the tests what the intent of the code is.
2. Talk to the Person Who Wrote It Communication is key, if you have the chance to talk to the author of the code you’re working on you can get some insight if you’re having trouble.
3. Remove All Warnings This ensures quality of code, and reduces code rot.
4. Refactor Changing the internal structure to make it easier to understand without modifying behavior.
5. Leave it Better Than You Found It Do your due diligence when it comes to maintaining quality for you, and future people working on the same code.

I chose this resource because it gives advice on working with other people’s code, working with existing test cases, or adding your own. It reinforces the idea of clean code because you should leave the code better shape than you found it (if that’s possible). I feel the article had some good information that I will definitely use in the future. I will be working with code that was written by someone else, and will need to write test cases for changes made to the code and maintain it still functions the same. I learned techniques for dealing with code written by others, and doing my best to respect the original purpose of the code.

The post How to Work With Someone Else’s Code appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

Clean Code Principles

In this blog post, Marcus Biel gives his thoughts on clean code, what that is, how to implement, estimate, and accurately design good software that does exactly what it should and nothing more. What is clean code? The author writes,

“It’s the idea that your code should be precise and as close to perfect as possible. If you have more code than you need, it shouldn’t be there.”

This concept relates to YAGNI (you ain’t gunna need it), and is an essential part of having clean and readable code. Adding features that might be needed later is a good way to bloat your code and run into bugs. Clean code requires time to fully understand the problem, this is sometimes tough when working in an environment where you are being pushed by those who don’t understand what goes into software design. Sometimes you will be asked to meet deadlines that will make you rush, in turn you can end up with poorly written code. The language and wording in code is also very important, using variables and names that are clear and make sense help others read and understand what is going on in your code. I selected this resource because having clean code is a huge part of being a good programmer, along with tips on clean code, the author has tips on designing code by running tests first, working with co-workers and clients to understand what features are most important, and what features are not beneficial.

“To me, being a software craftsman is about having a focused attitude and about taking responsibility for your code, your job, and your time. So, from beginning discussions to end results, your one focus should be on maintaining your own high standards and creating the best possible product for your client.” – Marcus Biel

This post had a good amount of information and insight on clean code, and being a good developer in general. Important aspects from the post I think are being clear when naming variables, methods, and classes, leaving out code that is not needed (YAGNI), and making accurate timelines for projects. Rushing to write code before you fully understand the problem can lead to more problems down the road. I expect to use concepts of clean code in my professional career, I believe it’s very important to make a good product that will benefit you, your company, or your client.

The post Clean Code Principles appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

Singletons: Bill Pugh Solution or Enum

In this blog post, Harinath Kuntamukkala discusses different approaches to the Singleton pattern. The first implementation he goes over is the Bill Pugh Solution, which is similar to the implementation we learned in class except it uses a static inner helper class as in the example below:

public class Logger {
    private Logger() {
        // private constructor
    }
    // static inner class - inner classes are not loaded until they are
    // referenced.
    private static class LoggerHolder {
        private static Logger logger = new Logger();
    }
    // global access point
    public static Logger getInstance() {
        return LoggerHolder.logger;
    }
    //Other methods
}

This would be the best approach but it’s possible for more than one instance to be created with the use of Java reflection. For example:

public class LoggerReflection {
    public static void main(String[] args) {
        Logger instance1 = Logger.getInstance();
        Logger instance2 = null;
        try {
            Constructor[] cstr = Logger.class.getDeclaredConstructors();
            for (Constructor constructor: cstr) {
                //Setting constructor accessible
                constructor.setAccessible(true);
                instance2
                    = (Logger) constructor.newInstance();
                break;
            }
        } catch (Exception e) {
            System.out.println(e);
        }
        System.out.println(instance1.hashCode());
        System.out.println(instance2.hashCode());
    }

The solution to the problem suggested by Joshua Bloch, is to use Enum. The reason we use Enum is because Java ensures that any Enum value is instantiated only once. Using Enum, this is what the Logger class would look like


public enum Logger {
    INSTANCE;
    //other methods
}

It’s still possible for more than once instance to be created if a singleton object is serialized, then deserialized more than once. In order to avoid this you can implement a readResolve() method in the Logger Singleton class:


public class Logger implements Serializable {
    //other code related to Singleton
    //call this method immediately after De-serialization
    //it returns an instance of singleton
    protected Object readResolve() {
        return getInstance();
    }
}

The reason I chose this resource is because we are currently learning about design patterns and just reviewed the singleton pattern. This post goes into the best implementations of the singleton pattern and why that is, I would like to stay on-top of the most effective, clean and efficient implementations of design patterns. I think this is a useful post, and learned about the Bill Pugh Solution and the Enum solution to ensure there’s only one instance of a singleton object. The author concluded that the Enum approach is the best solution as it is

“functionally equivalent to the public field approach, except that it is more concise, provides the serialization machinery for free, and provides an ironclad guarantee against multiple instantiations, even in the face of sophisticated serialization or reflection attacks.”

I expect to take what I learned in this article and use it whenever implementing the singleton design pattern, and I might rework the code I have now to make use of the Enum approach talked about in the article.

The post Singletons: Bill Pugh Solution or Enum appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

Single Statement Unit Tests: Making tests more object oriented

In a post by Yegor Bugayenko, Single Statement Unit Tests,

“..I believe, can help us make our tests, and our production code, more object-oriented. Here it is: a test method must contain nothing but a single assert.”

He makes use of the assertThat() that is available from Hamcrest. Benefits to using assertThat() are: Reusability. Classes needed to create test assertions are reusable in other test methods and test cases. Brevity. Shorter and readable code that’s easy to understand. Readability. Using a single assert, the intent of the test will always be apparent. Immutability. No need for setters or getters if we limit use of algorithmic code in tests.

He uses and example method RandomStreamTest from OpenJDK 8, created by Brian Goetz:

@Test
public void testIntStream() {
final long seed = System.currentTimeMillis();
final Random r1 = new Random(seed);
final int[] a = new int[SIZE];
for (int i=0; i < SIZE; i++) { a[i] = r1.nextInt(); } final Random r2 = new Random(seed); final int[] b = r2.ints().limit(SIZE).toArray(); assertEquals(a, b); }

In this example there are two parts, the algorithm which creates two arrays of integers and the assertion which compares them using assertEquals(). The author recommends modifying the code to look like this:

@Test
public void testIntStream() {
final long seed = System.currentTimeMillis();
assertEquals(
new ArrayFromRandom(
new Random(seed)
).toArray(SIZE),
new Random(seed).ints().limit(SIZE).toArray()
);
}
private static class ArrayFromRandom {
private final Random random;
ArrayFromRandom(Random r) {
this.random = r;
}
int[] toArray(int s) {
final int[] a = new int[s];
for (int i=0; i < s; i++) { a[i] = this.random.nextInt(); } return a; } }

The change is the test is that there is only one statement in the method now.

Yegor notes

"The biggest benefit we get when this principle is applied to our tests is that they become declarative and object-oriented, instead of being algorithmic, imperative, and procedural."

I chose this resource because it's an interesting way to design tests and the benefits of using assertThat() might be of use to me in the future. I think it is important to keep up on the best unit-testing practices if I want to write good code to match. I'm also interested in looking more into Hamcrest.

Using assertThat() allows you to write relatively short test cases that are clear what is being tested. Sometimes tests can become bogged down with too many assertEquals() and setters and getters. Using assertThat() allows you to simply compare two immutable objects. I plan on using this, or at least trying to implement it whenever writing tests in the future along with whatever makes writing tests more readable, understable and object oriented.

The post Single Statement Unit Tests: Making tests more object oriented appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

The Importance of Patterns in DDD

In this post, Jan Stenberg describes a conference in Amsterdam lead by Cyrille Martraire, Founder of the Paris Software. Martraire stresses the importance of knowing and evolving design patterns. Noting a few examples,

“…Exceptional Value which makes it possible to write code as a business domain statement by removing all need for special case handling like dealing with illegal or zero values. Another pattern that he has found particularly interesting is Diagnostic Query, a pattern which suggests that an object should be able to describe how it reached its current state, a diagnostic ability that replaces the need for logging and debugging. A Money object with a value of 100 EUR could then describe that the amount came from adding a certain amount of GBP with an amount of USD.”

In reference to modeling domain concepts and their relationships, Martraire found these patterns to be very useful:

Composite for composing objects into tree structures and letting a client treat individual objects and compositions uniformly.
Interpreter for evaluating sentences in a language.
Flyweight that uses sharing to support large numbers of fine-grained objects.
Strategy for separating algorithms themselves from their usage.

Martraire says that learning and implementing new and sometimes more simple design patterns will help you apply them in new domains.

The post The Importance of Patterns in DDD appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

The Business Case for Unit Testing

In this post, Erik Dietrich talks about the importance of making sure developers are well-trained in writing units tests.

“If you have developers writing good unit tests, you’ll develop a nice, robust unit test suite over the course of time. Developers will run this test suite constantly, and they’ll even have the team build to run it in a production-like environment.”

Making sure your units tests are well written and easy for maintainers to understand helps prevent regression, like a developer editing code and breaking functionality elsewhere.

“Testable code is better code, as measured by how easy it is to change that code.”

Writing better unit tests allows for bugs to be caught earlier and increases functionality and modularity, saving businesses money and making you a better developer with a more productive team.

The post The Business Case for Unit Testing appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.