Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Google Podcasts | Spotify | RSS | More

Meet our next guest, Allan Kelly. Allan began his career as a software developer but quickly moved into consulting. He has authored several books on software development and shares his love of tech and how to be more efficient in software development with others in the industry. Listen in to episode 60 and hear his story.

Say hello to Allan on Twitter!

Allan’s Bio:

Allan makes digital development teams more effective and improves delivery with continuous agile approaches to reduce delay and risk while increasing value delivered. He helps teams and smaller companies including start-ups and scale-ups with advice, coaching, and training. Managers, product, and technical staff are all involved in his improvements.

 

Allan is the originator of Retrospective Dialogue Sheets and Value Poker. He is also the author of four books, including “Xanpan -team-centric Agile Software Development” and “Business Patterns for Software Developers” and more recently “Continuous Digital: An agile alternative to project”. On Twitter he is @allankellynet.

Episode Highlights and Show Notes:

Arsalan: Hi everyone. Welcome to another episode of mentoring developers. Today my guest is Allan Kelly. Allan, how are you?

Allan: I’m very well. Thank you for asking me, Arsalan.

Arsalan: I’m so happy to have you here. You are not in the US. You are in London. Is that correct?

Allan: Yes. I’m sitting here in sunny London. No rain today.

Arsalan: That is incredible. I am so sorry that I have to hold you in your home office right now instead of out there having fun on those rare sunny days in London. So the question is, who Allan is and you told me that you are an Agile coach and you coach people and teams about how to do better. You mentor people. You have so much that you have done in your life, and we really want to go into that. There is one story about your first proper programming job that you got. That was five years after you graduated, and it was supposed to be this amazing new opportunity where you do things and it didn’t go according to plan. What happened?

Allan: I had already been earning money for programming before college. When I went to college I learned how to do it properly. You know that thing when you ask users what they want and you write it all down, and you design it, and you build it, and everything’s cool? I learned all that in college and then I graduated. When I got to the real world, nobody does it like that. It’s all over the place. I do these jobs because you have to earn money, but I spent five years feeling guilty doing projects after projects. I was thinking that we don’t do these things the way we’re supposed to. I was thinking that it was all wrong because we don’t do it how I was taught in college.

Allan: I started working this job for the British railway system, and they were doing it properly. Everything was written down, and they have an ISO approval on all the rest of it. I was so happy to get this job. It was a nightmare. The documentation was as high as a five-year-old kid. I spent half my week writing documents. We got audited and we were coached on how to answer the auditor’s questions. We had these architects who came from a Cobalt background and we were writing in C++. They had no idea about the technology we were using. So, the code and the architecture were two completely different things.

Allan: One day at lunchtime, I wandered into a bookshop that was close to the office. I found this book by a guy called Jim McCarthy. He’s still around and he’s brilliant. He opened my eyes and I suddenly realized that the way I was taught in school was a bit wrong. It never works out like that. It can’t work out like that. Jim laid out how his team at Microsoft does things differently. I suddenly no longer felt alone or the odd one out. That was in the late 90s. That was the start of my journey to the thing we now call Agile. So, I got to do it properly and it just didn’t work.

Arsalan: I have a lot of listeners who are just starting out and who may not know about all these processes were talking about. There is this idea that exists in academia and a lot of other circles where you talk about with the best way is to build software reliably that will be maintainable and where the process that you follow is repeatable for high-quality software, just like you can do with other pieces of engineering. You can say do this and you will result in having a very high-quality piece of software with fewer bugs, fewer defects, and it will work as expected and everything will be great. Then we have this idealized notion of how to build software. We go into the real world and we see that has flaws. Tell me a little about the issues you faced.

Allan: We were doing software about trains and how trains move around the network. One problem we had was with a source control system, but when you check something and there’s a load of paperwork. So, you had to fill in these forms before you could check something in and you had to get a line manager to check in your code. It slowed everything down. Once your code was checked in, the form goes to the testing department who builds your code and they test it. So, one day we do this and it gets sent back to me with the book report that said that my train was doing this and it shouldn’t be doing that. I asked if they were sure. I went and talked to the testers.

Allan: We realized that what it said in the requirements department of what the train should do and what the trains actually do in real life are two different things. There’s this one station where the trains go in and come out in an odd way. According to the manual, it never happens. So I mentioned that we know that trains do this. So I was told to speak to one of the customs people. But I’m also told that I must find out what the trains do in real life, but not let on that the document says one thing when we think something else, because that’s a contract issue, and they have to escalate it.

Allan: This is a project where we are working six days a week. On the seventh day, you carry a pager back in the pager days because the testers are working seven days a week. So, were trying to do as much as we can and as fast as we can. Yet, we have all these paper forms flying around and all these conversations that don’t exist because you’re not allowed to talk honestly to your customers. There are all these barriers because we’re doing it properly. It was utterly crazy. The way you can write something down, and the way things happen in real life will never meet. The more you write it down, the more complicated it gets. The more you write it down, the lesser the people will remember if they do read it.

Arsalan: These things happen because as we discover that people don’t just turn up one day and they are enlightened software developers. They have a history. They have some baggage. In your case, there were some programmers who were perhaps coached and trained in a completely different coding paradigm. They are experienced, but they are not necessarily well-versed in this methodology and programming languages. Also, people have their quirks and software development is not an exact science, unfortunately. I believe it’s more like Ninja, Kung Fu stuff.

Allan: Yes. It’s a bit of everything, isn’t it? I believe software development is engineering. I also believe engineering requires a bit of inventiveness and a bit of art. I know there are people who argue about whether or not it’s engineering. I say were not good enough to be engineers. We had to get one haven’t quite mastered it. The thing is, most people who talk about software ring engineering don’t know much about engineering. There are lots of different types of engineering. I’m a 3^rd generation engineer. My father was an engineer. My grandfather was an engineer. They really had oil under their fingernails. They were ship engineers. At times, they built ships. They spent most of their lives making ships work.

Allan: As a kid of seven or eight, I’d been down to ships’ engine rooms. I saw ship engines over hulls. That informed me. I know that when you’re engineering things, that’s how the engine should work, but it doesn’t always work like that when there’s a bit of dirty oil in there. Or, the ship has to sail but the guys haven’t finished the maintenance. The ship has to sail…there’s a commercial imperative there. The idea that many people have about engineering and why they think software is a form of engineering is because they aren’t really informed about actual engineering. Engineering is the art of the possible. Engineering is making things work within constraints. That is absolutely what we do in software and it does require some innovation and some imagination, blue sky thinking, call it what you will. There are a lot of different things in there. I think that’s all part of the engineering mix.

 Arsalan: Right. So, it’s not clearly defined and it’s somewhere in the middle. Let’s talk about you, Allan. We want to understand who you are and where you’re coming from. Tell me a little about yourself. Let’s let our listeners understand who you are.

Allan: Who I am? I am Allan Kelly. I live here in London. I used to be a programmer. I used to put my fingers on the keyboard and write code. I still think of myself as that kind of person, although, no one has paid me to code for many years. I still have my pet projects at home, but when I work with teams and developers I see in them many of the frustrations that I had as a programmer. I reached a point a few years after I turned 30 and realized that I could make the code fly. I could make the code do what I wanted it to do. The code wasn’t a challenge for me anymore. The challenge was the way we are asked do stuff and the way we are set on teams.

Allan: Once upon a time a guy in his bedroom could write a program and he could make a lot of money. As a teenager, I was that guy. I didn’t make a lot of money. I made a little bit of money. I never had a Saturday job. I never delivered papers or anything like that. I never worked in a shop. I used to write programs in my bedroom and I used to them to TV, magazines, BBC, and people. That was how I had money as a kid.

Allan: Code is still a problem for a lot of people. What makes it so much more difficult is the way they are expected to perform, the structures that are put in, the way they are managed, the way their teams are sorted out, and the way the needs and requirements reach them. So, when I work with teams and managers, I see the problems they are having and I know those problems. I have lived that life. I want to help them with that problem. Before we can fix the problem with their code, we have to rethink how they’re going about structuring the code. It’s the structures, the organization, the culture and everything around it. When you’re setting up a code, what are you thinking about? Can you think clearly about your code? Or, are you worried about something else? It’s all about the environment that you’re in.

Allan: I still think of myself as a software engineer, but I don’t write the code directly. I influence how the code is written by helping teams and organizations do a better job. So, that’s what I’d say about myself if I’d had a few drinks at a party.

Arsalan: What was your first encounter with programming? How did you even know that was the thing to do?

Allan: I grew up in Liverpool in the 80’s. It was when home computers were just coming in. One of our neighbors bought a Tandy TSR80 from Radio Shack. I’d watch him and his dad typing in programs. I wanted some of that. So, I persuaded my mom and dad to buy me a machine. It was a ZED X81. That was what we called them here. It was a ZED80 machine with 1K of RAM, which, after a few months we got a PAC with 16K, not megabytes, K.

Arsalan: That’s kilobytes, people.

Allan: That’s kilobytes, yes.

Arsalan: And people are wondering what a kilobyte is. I haven’t heard that in a long time.

Allan: That’s like a thousandth of an MB, not a thousandth of a GB. So with this machine, I had found my thing. I was just hitting my teenage years. The machine and I used to commune. I moved up from this one K machine to a 2K machine with a 6502 processor. I spent most of my money for it. I used a little of the money and bought a book on machine code. So, I used to write 6502 assembly stuff. When I got a bit more money I could afford a Pascal compiler. As a self-taught programmer, I had go-to’s all over the place, but there were no go-to’s in Pascal. So I had to relearn how to program in a proper fashion the way you’re supposed to. That has still stuck with me.

Allan: I’ll tell you a funny story. When I was 16, like most 16-year-olds here in England, you do your first proper school exams where they get marked and recorded forevermore. I was one of those kids who did computer studies back then. We had to do a programming project as part of our assignment. One of my teachers had it in as one of the examiners. He told me a year or two later that I scored 98% and the programming assessment. Do you know what I lost 2% for? I didn’t use a go-to.

Allan: The exam board had this list of things that you had to do to demonstrate that you could program. One of the things that you had to demonstrate was that you could use the go to. Had I known that, I could’ve put a go to in there somewhere.

Arsalan: That’s a problem with computer science education because the teachers themselves are not equipped or trained. We follow these checklists of things. It happens now as well. You have to do this because it’s in the curriculum even though the rest of the world has realized that it is bad practice to do it.

Allan: Yes, so this is a really key point. It was one of my first big moments when you realized that those experts aren’t necessarily right. It’s like where I’ve mentioned before that, on a project where we were doing it properly. Doing it properly was hell. What is happening is with our education system and the people who are coming out of our education system of certain models. But because our technology is racing ahead, our technology is already invalidating some of those models. So if you go back to the traditional model that we used to develop software, we call it the waterfall because you have to get out the requirements and do the analysis and do the design and on and on. That makes perfect sense if it’s 1970. That model comes from 1970. We’ve spent the 70s and 80s perfecting that model.

Allan: Let me remind you of something. I’ve read up on this and most of your readers could read up on this as well as they want. In 1970, we had teletypes to communicate with our computers. If you had a screen, it was a green screen. We programmed our computers in Cobalt on an IBM 360 OS mainframe. The IBM state-of-the-art mainframe had 4 GB of RAM and 10 MIPS of processing power. My eight-year-old has a Raspberry Pie and it has 4500 MIPS of processing power and 1 GB of RAM. It is 2017.

Allan: That traditional software process that we’ve been taught makes sense if you’re programming IBM mainframes in 1970. In 1970, CPU cycles were really expensive. Paper and desk time were cheap. In 2017, when you’re programming your Lenox or Android in Ruby or Closure or one of these other modern languages, CPU cycles are now so amazingly cheap. That machine in your pocket has spent more cycles than Neil Armstrong going to the moon. Now that CPU cycles are so cheap, paper and dust time are expensive. It’s far cheaper and we can try out new ideas and get a quicker feedback loop. But, many of the things that are still being taught stem from an earlier age wall we’re racing ahead. The trick is to spot what those earlier lessons we keep and which we move on from.

Arsalan: Okay. That’s very wise because we are constantly going to always be learning and evaluating our successes and failures. Over time, the software industry tends to get better. We tend to understand how this works better. I think you will agree that context is also very important. What works in a very rigid scientific environment or an environment where the requirements don’t change, your requirements as a software developer per or your methodology may be very different from something else where you don’t understand the problem that you are iterating.

Arsalan: We’ve talked about Agile. You’ve referred to it a few times and mentioned that we didn’t have this term Agile before. You’d also don’t necessarily like this term because it doesn’t encompass everything. So, tell us a little about what you mean by all this.

Allan: The only thing that you can really do wrong. If you claim to be Agile, is to do things the same way that you did them three months ago. You should constantly be experimenting, innovating, and trying new stuff. Some of it is going to work and some of it is going to fail. I say that in and Agile context, but really that applies to all software development. That’s because software is always changing. By definition, when we create software, we are creating something new and innovative. If it already exists, you’re going to reuse it, take it and download it from source Forge or somewhere. If you have some code that already does it, you aren’t going to write it again. Instead, you’re going to do control C and control V. You’re going to copy it.

Allan: When we’re writing code, we are always doing something new. We are always innovative. All software development is about learning. We are learning about our tools, our languages, and our options. That’s the most obvious thing. We are also learning about the problems we are solving. Whether you are creating medical equipment or train software or iPhones, you’re learning about the problem you’re trying to solve because we don’t really understand the problem that we’re trying to solve. We think we do. But the truth is that as we are creating the solution we view the problem in a different way. The next time you’re having trouble getting email on your phone, that’s a new problem. How many people 10 or 15 years ago knew that we would get email on a phone? How many people 10 years ago knew that they needed to send 140-character message to the world?

Allan: We are constantly doing new stuff. As we are doing this new stuff, we are thinking of new ways of approaching it. We redefine the problems we are approaching and addressing. We create new problems to solve. So, the second thing that we’re learning is about the thing that we’re creating. The third way that we are learning is about the processes and actions that we are going to use to go about doing this. To some degree, we are learning about learning. For me, all of our technology and software is a multi-layered learning process and we are constantly layering.

Allan: I think that the traditional model, the thing that we call waterfall, tried to freeze learning and tell us that we’ve learned all about the problem. We have written it down. We have now studied the architecture and we have written it all down. We will now give it to a simple programmer who will code something up and when he is done, that will pass the test. We try to put in boxes and freeze it, but what we see is that those boxes feedback to one another. Over time, as we’ve gotten faster, our cycles are getting faster and faster. Our chain cycles are getting faster and faster. So those boxes are interfering with each other at a faster rate. The big thing about Agile is that Agile suggest that we have a model that incorporates learning. It’s the kind of model where we do something and see what happens, we think about it, we reflect on it, and maybe that changes what happens.

Important Links

• AllanKelly.net

 

Thanks for Listening!

Do you have some feedback or some advice for us or our audience? Please give us a review on iTunes, Spotify, Google Podcasts, or Stitcher and share your thoughts.

If you found this episode useful, please go ahead and share it with your friends and family. You can also listen directly and give your feedback on the website.

You can subscribe to Mentoring Developers via iTunes, Stitcher Radio, Spotify, or Google Podcasts. 

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Google Podcasts | Spotify | RSS | More

Special guest, David Gatti has returned to Mentoring Developers. This time, he discusses the importance of internet security and what he has to say may surprise you. Don’t miss episode 59! Arsalan and David talk about usernames, passwords, and the importance of proper authentication.

Say hello to David on Twitter!

 

David Gatti’s Bio:

David Gatti began his career in IT as a Systems Administrator. He learned how to code in PHP out of boredom, and made some simple internal tools to help him while managing the company network.

He then became a blogger and wrote about mobile technologies before the iPhone came into existence and PDAs had cellular modems. He also wrote the CMS for the website itself when WordPress was first starting. Then he began working as a web developer for a company that did simple Facebook games.

After this initial experience, he imported a Windows Mobile app to Android 2.3. He later became a Brand Manager for a mobile game company and a Marketing Director for another company, and at that company – he transitioned to Developer Relations Manager and worked for two companies with this title. It was a job that he fell in love with.

But, while hunting for his next opportunity, he struggled to find the right company. Out of frustration, he created Simpe.li (simply) so he could keep doing what he does best – Development Relations Management done right.

Episode Highlights and Show Notes:

Arsalan: Hi everyone. This is Arsalan Ahmed with David Gatti. David, how are you?

David: I’m fine. How are you?

Arsalan: I’m great and today we’re going to talk about security in the sense of how to keep our server secure, how to build websites that don’t get hacked. Those are important. We are going to talk about how to keep our users secure, how we can avoid becoming hacked ourselves, and how we can have secure practices as software developers. For someone who is starting out and learning these new programming languages and frameworks to build cool apps, they may not be thinking about security. They should pause and listen to this podcast and really think about what they’re doing to ensure they’re not skipping something that’s important.

Arsalan: You had a personal experience with that. You had a new website and it got into really big trouble. So tell us a little bit about that, David.

David: it was for a website that was built more than 10 years ago. I developed it myself. Back in the day, we used the technology called STP to transfer files to the server. I had this STP client. I decided to make my life easier by saving my password to the server. By doing that, I ran into the situation where I got a virus on my Windows machine which detected that I was using this STP client and it try to access every website that I had in my favorites. It found my website, which was gaining popularity with over 7000 views a day. So a bunch of people was visiting it. This virus then updated my index HTML file with a piece of JavaScript code and started infecting all of my visitors with a virus. I received a bunch of messages letting me know that something was wrong. I fixed it, but it took me a while to understand how someone accesses my server.

David: After a while of googling around, I realized that the STP client that I was using had a common line interface which allowed the virus to easily use this client from the common line. Just by making my life easier and saving the password I had compromised my security pretty badly. After that situation, I started taking security more seriously and I started to make my life a little more annoying by not remembering passwords.

Arsalan: So there are a lot of things that we can do to keep ourselves more secure at different levels. So, one thing is to not get hacked or get a virus and one of the ways to do that is to have long, difficult to generate passwords. If somebody just wants to randomly create numbers and letters and try to break your password, of them a hard time. If it’s a longer password, it’s going to be harder. If it’s a random password, it’s going to be harder. So, that’s one level.

Arsalan: One thing that we talked about earlier was that we shouldn’t have the same username and password combo for every website. You can. A lot of times we use email addresses. So, if you use email addresses, then often your password is going to be the same.

Arsalan: If someone cracks your password on one website, they can try to gain access to other websites using the same username and password combos. Sometimes I don’t even have to work hard for that because there is a way for them to send you an email the link to all these different websites. Maybe it’s a link to something else that triggers a call. Perhaps it’s a form submission to another website. They’re hoping that you’re still logged in. That’s another type of attack. It’s called C surf. They can go in there and get access. Or they can go in there themselves and use a password, so that if you are logged into Facebook. Their hope is that you may also use the same password for linked in, for example. Or, maybe you use the same username and password combo for Yahoo mail and Microsoft email or your Gmail. It depends on how you set it up.

Arsalan: The point is to keep everything separate. If you have different usernames and passwords for every website, keeping track of it becomes hard, but you really want to keep it separate. So, how do you do that?

David: Let’s go back for a moment to talk about using the same password for different websites. We’ve already had situations over the years where Yahoo was hacked and there were password leaks and people tried to use those passwords to access information on Facebook and other websites. It was working because everyone wanted to try to make their lives easier by using the same password for different places. So, I have a different password for every website. This is what I started doing. I started using passwords like Last Pass. It’s a nice app that allows you to store all the password security in one place and have one master password and auto fills the forms when you go to a website.

David: Nowadays I’m using Keychain on my Mac because it’s a built-in feature and it’s more convenient. The cool thing about this is that you don’t have to remember all the passwords. This way, even if someone stole my passwords from one system, it won’t work on another.

David: I go one step further than this by always trying to create a new email for each account that I have. So, I use Gmail and Gmail allows you to create aliases very quickly. So, I do that every time I add a new account. So even if you get my password, it won’t work in a different place because you need to know which email I used. So now suddenly you have two things that are different.

David: I also try to enable to factor identification on all the sites that support it. This way the email is different, the password is different, and you have a second device that you need to use to authenticate the account. People say that I’m crazy, but I’ve experienced this thing and I feel good because I’m secure about the technology and computers and I’m confident that I won’t have any problems. So after that last incident, I decided to make my life a little more annoying, but at least I’m trying to do the right thing.

Arsalan: The flip side of the equation is where we’re talking about people who are developing websites for users. We do want people to come to our websites and feel secure. Not only do we not want our passwords to be out in the open or have other people gain access to our accounts, but we also don’t want our users to lose access to their accounts. So there is one thing that we can absolutely do and a lot of companies and websites are doing it already.

Arsalan: So, for new or aspiring developers who are starting to build websites, let’s make sure that we force people to use secure practices – our users. How do we do that? We can make them use strong passwords and not allow passwords that are weak and can be easily hacked, guessed, or generated. So, the minimum password length should be pretty long. That’s one idea.

Arsalan: Another thing that I’m really surprised by is that a lot of websites that I visit do not allow spaces or special characters in passwords. That makes it very hard to randomize a password. A lot of people have talked about this XKCD comic where a guy was explaining that if you have a long phrase that’s easy for you to remember “I have a horse that is brown.” It might be an easy phrase to remember, but it’s a lot of words. If you can toss in a special character that isn’t used a lot that can throw them off a little bit, but some websites don’t allow that. So, one thing you can do is that when you build a website that you do allow it. You can also encourage people to have strong passwords. We also talked about two-factor authentication.

Arsalan: So, let’s talk about the two-factor authentication a little bit for people who don’t know.

David: Yes. So, two-factor authentication is a very simple thing to implement because there are modules and things that people have already written. This is an old standard where you generate a random string of whatever and you keep this string on your server and you send it to the user. The idea is to display a code on your page where the user can use an app like Google Authenticator and scanned the code, which has a secret. So, now the server has the secret. And your phone has the secret. There are two places that have it now. Then, based on the time, a six digit pin is going to be generated. So, every 50 seconds you get a new pin based on the secret key.

David: The cool thing is that the two devices do not have to communicate with each other. They can be off-line completely. This way there is nothing that someone can hack to the communication in any way. They might be able to see the pins on your page, but the pins would stop working after 30 seconds anyway. The flow is very simple. If you had this feature on your website, the user could go there and click enable and they would receive this code that they have to scan. Immediately there app is going to pick this up and display the first pin that is generated. Then they put the pin on the website to confirm that they are able to factor authentication correctly. If the pin is correct, the user is enabled.

David: Now, the next time they try to log in. They type their login and password. The page will ask for their six digit pin to verify they have access to the second device. The idea is to not send this piece of information to the same device that you are trying to log in from. So, if we were receiving an email with a pin, it’s kind of pointless because you would be using it on the same device that you are trying to log in from. That’s why it’s important to have the two factors on a completely different device, and ideally with zero communication with the Internet.

David: So, it’s a very simple thing to implement, especially with NodeJS. I don’t know for sure with different languages if they have the same libraries that you can just use.

Arsalan: It’s something that’s coming up. It’s not universally implemented. There are different ways of doing it. As you said, two-factor authentications basically mean that you don’t just rely on username and passwords. You have another way of authenticating. Usually, you enforce that. Sometimes, you have an option.

David: The thing to remember is that if people are not mindful about security, they will not know that anything even exists. So, that’s one sad part about the situation. The second thing is, they may think that the two-factor needs to be completed in a way like banks use them. For example, you were given a dongle that you had to carry with you that was generating those pin codes based on the secure string. So I think in people’s minds they may think that two-factor authentication is too complicated and they don’t have time for this or the knowledge to do it. In reality, it might take you three days to do it from start to finish. It’s very simple and easy. So, if you’ve heard of it and thought about doing it then just do it. I can guarantee that it’s very simple. It’s not complicated and the flow is very easy to follow.

. It’s not complicated and the flow is very easy to follow and adds a lot of security to your account.

Arsalan: Yes. It makes you look professional. A professional developer should think about the users and their own well-being and security. That is very easy. Now, these days because there is a very popular Google authenticator app that has a presumably easy API to use.

David: You don’t need an API. That’s the cool part. Completely off-line. The app just reads that secure string. You can either do it with a core code to make it easier for the user, but there is another option where you can type it in by hand. There’s no API or anything like that. The app is just there to make your life easier.

Arsalan: So essentially you have some kind of a string or a key as you mentioned. That key is using a known algorithm from which you can generate a token or a number with that. You can only do it if you have that random thing that you just generated. Since you are the website developer, you’re the one who generated it. So you have it. By the Google authenticator scanning that, they have it too. So, now only two entities in the world have it. Using the same algorithm, they are going to generate the same number. Once you’ve entered it, it’ll be very easy for the application to know. You don’t have to enter this because there are plug-ins and libraries and lots of other different ways of doing it. If you want to do it, you can, and it’s a very good idea to do it.

Arsalan: While were added, let’s also talk about HTTP and HTTPS, which is another thing that’s easy and even I’m guilty of doing that. If you go to mentoring developers.com, it’s on HTTP, not HTTPS. I didn’t get around to doing it, but it’s very easy to do these days. HTTPS is a secure version of your website. The way it works is that you use SSL or secure socket layer. Then you need a certificate on your website that tells everybody that you are a legitimate purveyor of website content. You are who you claim to be.

David: Yes. The point is to tell the website visitors that you are who you are pretending to be.

Arsalan: So, somebody has to trust somebody. There has to be some entity that we trust and that entity has to verify who we are. That entity provides us with a certificate, which we can then use to do encryption and the other entity will know for sure that we are who we claim to be because they also trust that other entity. Those entities are called certificate authorities and now there is a free one. It used to be that you had to pay a lot of money, but now you can go and get a free SSL certificate. So it’s very easy to do and it’s a reminder for me as well because I need to do it.

David: The good thing is that the free part is if you use Heroku, they have a built-in now. You can literally enable https for your website by using the automatic option and they use an encryption to do it. So, you just push one button and it’s done. You don’t even see your certificate. You don’t have to copy it. They just set it up automatically for you. Every three months. They will automatically generate a certificate for you because that’s how long those certificates last for you.

David: If you were to do it on your own server, then it’s a little bit of a pain in the butt. You have to run the script and set up everything. It’s a little more annoying. But if you use Heroku, then it’s one push of a button.

Arsalan: Right, and there are probably lots of people in the audience who are wondering right now what Heroku is. So, let’s just talk about it quickly. Heroku is a platform that allows you to deploy your Web servers, web services, websites, and whatever applications you have into their servers. It’s a cloud-based service.

Arsalan: So, if you were developing a program in NodeJS or Ruby on Rails or Python or whatever, it’s a website that you want people to access. You can have your own server deployed there and you can find a shared host or you can deploy a service like Heroku. Heroku allows you to deploy directly from your depository, such as your Getup account and once you’ve updated, it gets the new version and compiles it, runs a test and deploys it all for you. You save money because you only pay for the time that you use. This is very similar to what you can do on other platforms like Amazon, EC2, Azure, and some others. Heroku is very seamless from a development point of view. That’s why we talk about it and you can start for free. So, it’s very easy to get started.

David: The cool thing about it is Heroku uses EC2 machines. So, they’re using Amazon, but they’re putting a nice clean interface to interact with the craziness that Amazon is because the interface there is super crazy and complicated. When you have a lot of products like that. It’s not an easy thing. At Heroku, they just made it super simple to deploy and have it working. If you’re on that platform, it’s simple to enable SSL now. That’s especially important whenever you try to send any type of forms because if you don’t enable a secure connection everybody in the network is able to read everything that goes between the server and the client. So, the point is to make sure that you are not only connected to the website that you wanted to connect to but when you try to send information back to the server that stays private to the browser and the server. That way nobody else can see what is going on.

Arsalan: Excellent point. If you connect to a website that runs on https, which means that uses SSL certificates then all of that information is encrypted. So, only the person with the key that was negotiated during the SSL handshake can read it. That’s why Google is really pushing for it. Google at the search engine level likes to have all websites in https. It’s a good habit to have, but most websites today are not running on https, including mine. So it’s a reminder to me and everyone else to look into that. It’s very easy to do it.

David: I have it more for my private website which has no forms. It’s just the display with text on the page. I also enabled it just to do the right thing by default. Don’t even question it. It’s something that you might think is complicated because when you’re developing, you just want to develop something and you don’t want to think about this. But, sadly, many young developers forget about it. They don’t think about securities. This is not something that they are interested in for example. They just want to develop. If other people are going to use it, you need to start taking security seriously because other people’s lives are going to be impacted by what you create and how you created it.

Arsalan: There is a feeling that front end developers are not that interested in security. They don’t want to talk about it or think about it. They just want to build their functionality. So we’re going to talk a little bit about this. There’s a question on Stack overflow that caught my attention. I think we’re going to include the link in show notes. So, if you’re listening to this podcast right now, go to the website and the page for this episode. You’re going to find a link where there’s a nice answer with a whole bunch of bullet points.

Arsalan: The first point is to never trust any input. I think that’s a very good point, especially when it comes to front-end development. What’s your experience with that? You work with front end developers. What do you think about this, David?

David: The important part to realize is to never trust and input, but in the front end it’s not such a big deal because the front and is responsible for creating a good user experience. For example, let’s say you’re trying to enter your password and you have forgotten what it was. You should always check to make sure the inputs are all correct on the backend. The backend is where no one, in theory, has access. In the backend, you can ensure that the password is in place and is the right length. You can also ensure that the email is correct. You can also ensure the email is the right format. If you only make those checks in the front end, anyone who is visiting your page has access to that go to JavaScript code and can change anything on your website.

David: This is something that I realized a lot of people don’t think about. So, doing those checks on the front end is for user experience. Doing those checks on the backend is a security thing. The backend should be the last place to check and make sure that everything is correct.

Arsalan: So, we have different layers of security. When you have validation, you should have validation on the client and the browser because that’s fast and efficient. The ultimate validation and security is in the backend because that is where your data live. If you are user interface gets garbled because something happened, that’s okay. You can just reload the page or closure browser and start again as long as your data are good. You don’t want bad or untrustworthy data to get into your system.

Arsalan: So, let’s give an example of the different types of attacks or malicious content that can compromise your data or your application. There is something called SQL injection. SQL injection can be handled very easily. Let’s say you’re just starting out and you are building an application and you want to allow people to search for things. When you receive the text from the user, your plan is to use that to generate a SQL query to select something from a given table where this name, identity or field equals what you received from the user.

Arsalan: If you make a naïve query like that you are setting yourself up for an attack in the form of bad SQL input, which will run a random SQL query on your website and they can probably make a guess on what your data structure or database looks like. Not only would they be able to extract data, they would also be able to remove or insert things. They can wreak all kinds of havoc. This is something easily fixed if you use best practices, but you have to know best practices in order to use them. If you know that, then that problem goes away.

David: Yes, and it’s also a good idea to use forms as an added layer of your queries so you’re not writing low queries. Another good idea for ORM is to make sure you don’t have SQL injections. So even if this is not your strong suit, just by using one of those forms popular ones, you’re safe, at least in that regard.

Arsalan: Right, so let’s talk about some of those ORMS. ORMS are the software packages or pieces of software that take an idea or concept that you have in terms of data. You want to get and manipulate some data and convert that internally into commands for the database, like SQL. You don’t have to implement SQL in your own code. You write your idea. For example, let me get all these records that fulfill these criteria. You give that command in the ORM language, whatever the ORM uses. It could be text-based. It could be API, like a fluent API or whatever uses. Then, it internally converts it. When it does, converted it makes sure to prevent SQL injection.

Arsalan: What David is saying is that if we use those software packages, which are built into a lot of programming languages like Ruby on Rails and more, you can use them. They are very popular. If you follow the best practices, it will become very natural and just happen. But in a lot of cases when you’re first starting out, you may not know them or be intimidated by them. You may think that you need raw speed or just to get down to the metal and see how things work. So, it’s okay to create your own queries, but just make sure you use parameter-based queries.

Arsalan: I’ve been in situations where I’ve seen raw SQL all over the place. In the real world, raw SQL is used. Sometimes people think that gives them extra power. Some people don’t trust ORMs. It is sometimes the case where ORMs are very slow. In the .Net world there is a Microsoft sanction and Microsoft entity framework which is a very nice framework because it gives you a very nice API and you can type queries easily. It gives you a lot of ability, but it comes at the cost of speed of execution. It’s very slow.

Arsalan: You could pick another ORM that’s not sanctioned by or developed by your company of choice, like in the case of ASP.net. So then you could find another ORM that is like a micro ORM. It may be a very thin ORM that gives you some protection and some facility without being overbearing and it’s still pretty fast. So, there are some options.

Arsalan: If you’re listening to this podcast right now, and you’re wondering what kind of ORMS you can use for the framework or program language that you’re interested in, send me an email. My email address is us@mentoringdevelopers.com. I’ll help you out or I can get you in touch with people who can help you out. We’d love to know more about your problems and issues, what you’re dealing with at work. If you are interested in security, we’re going to have a follow-up episode. I think this is a good length. We’re going to conclude this episode right now, but were going to have but were going to have a follow-up episode where we will go more in depth on ‘are our application secure?’ I think you’re going to really enjoy that episode if you liked this one.

Arsalan: The show notes and links for this episode are going to be on www.scientdev.wpengine.com/episode 59 because this is episode 59. We are going to have to stop now and continue in the next part of this episode.

Arsalan: So, David, what do you think? Do you think we were able to cover some important security topics?

David: Yes, I think it’s a good start, especially if you never thought about this. Good topics are good for yourself. Do some research. Read articles. Learn more. There is one more thing that might help you out. It’s called Security Now! If you Google it, you’ll find it. It’s by Steve Gibson. It’s way more advanced than what we’ve just talked about. He goes into all the smallest ideas when it comes to security. So, at first it might be very scary and daunting, but it’s a good thing to at least listen every week to get a general idea of what is happening in the security world. That’s because there’s a lot of stuff happening. There are people hacking others and different accounts every day and every second. There’s always something happening. This will open your eyes to this world and what it is.

Arsalan: All right. So, this has been Arsalan Ahmed with David Gatti on security. We are going to be back with more security. Go back and check out episode 59 show notes again at www.scientdev.wpengine.com/episode 59. Send me an email at us@mentoringdevelopers.com. What’s your contact info, David?

David: You can hit me up on Twitter at @dawidgatti or on instant gray. Those are the two best places to get in touch with me.

Arsalan: Awesome, and our twitter handle is @mentoring devs. See you guys later!

Important Links

• GRC Research
• Stack Overflow
• Heroku
• Stack Overflow
• Security Now!
• David Gatti

 

Thanks for Listening!

Do you have some feedback or some advice for us or our audience? Please give us a review on iTunes, Spotify, Google Podcasts, or Stitcher and share your thoughts.

If you found this episode useful, please go ahead and share it with your friends and family. You can also listen directly and give your feedback on the website.

You can subscribe to Mentoring Developers via iTunes, Stitcher Radio, Spotify, or Google Podcasts.