teleren/devto huggingface dataset:
Land Mines
Tags: softwaredevelopment, programming
Published: 2017-01-31 22:57:36

---
title: Land Mines
published: true
description: Avoiding land mines in your project
cover_image: 
tags: software-development, programming
---

Several years ago, I got the call every engineer dreads: there's a big problem in production. The issue manifested itself dramatically but was caused subtly. I had made significant performance improvements by altering a `SQL SELECT *` query to exclude a column containing a large blob of text. That text wasn't used in that page... or so we thought.

During the refactor, I identified that text _was_ used in one check, but after conferring with other engineers we decided it was OK to remove the field in this query anyway. It turns out that check was important. At some point years prior, the team decided that the presence of a certain substring in the large text blob would affect the value of a very important boolean field in a non-obvious way. Excluding that text from the SQL query, in certain cases, affected this important boolean value.

More recently, I noticed a different issue. Our API applied a default setting based on create date, because on a certain date the default settings changed. Seven months later, a change to the way we used a 3rd party library affected how we set create dates, which then affected the settings on very specific older data.

These decisions&mdash;changing a boolean based on a keyword in a large blob of otherwise unnecessary text, applying a setting based on create date&mdash;are land mines. They fix an issue at hand and lie silent for months or years only to explode when an unsuspecting developer makes a routine change.

Nobody likes land mines, but how do you prevent them?

**Avoid Shortcuts**

This may sound obvious, but it's so easy to take a shortcut and move on. In fact, that's probably the token signature of a land mine: a questionable decision made in the interest of time that solves the problem... for now. But please, think about future you, future me.

**Be Obvious**

When writing business logic, think about the inputs to your function. Would another developer reasonably expect change of input data to affect the output of your function? Try to imagine scenarios where your input data might change. Would this affect the output in unexpected ways? I don't think most people would expect settings to change based on the create date.

**Consider Migration**

In both of the instances above, a "dirty hack" was introduced to avoid running some kind of migration on the existing data. Migration is scary, I get it. But the outcome of avoiding a migration can be scarier. Migration is a tool in your toolbox that you should not be afraid to use. When weighing options, remember to weigh the obvious risk from migration against the not-so-obvious risk of introducing code complexity and possible land mines for future developers.

I hope these tips will help keep your codebase clear of land mines for all of us.
Global Scope Discussion (Jan 31)
Tags: globalscope
Published: 2017-01-31 17:15:20

---
title: Global Scope Discussion (Jan 31)
published: true
description: A discussion of current events. For programmers, not necessarily about programming.
cover_image: 
tags: global-scope
---

This is a discussion thread for issues that are important to the developer community but not necessarily code-related. If you have thoughts or issues, or are working on a big project and want feedback/help, please share. If you have questions about anything going on, please ask.

The thread is an experiment, but if people find it helpful, I think this chat should regularly. Don't feel like we need to cover everything in each thread, as it could act as an ongoing check-in on some important issues. As always, please be positive, constructive and helpful. In difficult times, we must treat one another with respect.
Hi, I'm Chris Hartjes
Tags: introductions
Published: 2017-01-31 00:30:38

---
title: Hi, I'm Chris Hartjes
published: true
description: My introduction post
cover_image: 
tags: introductions
---

I have been coding for money since 1998 and for fun since the early 1980's 

You can find me on Twitter as [@grmpyprogrammer](https://twitter.com/grmpyprogrammer)

I live in Milton, Ontario, Canada

I work for Mozilla

I mostly program in these languages: Python and PHP

I am currently learning more about coping with being a grumpy programmer.
A Quick Post About Resumes
Tags: resumes, jobsearching, jobs, jobadvice
Published: 2017-01-27 20:50:41

---
title: A Quick Post About Resumes
published: true
description: Resumes are the first look most companies get. Make sure you are putting your best foot forward.
cover_image: https://c2.staticflickr.com/2/1699/25388690154_681ec2856c_b.jpg
tags: resumes, job searching, jobs, job advice, programming 
---


[PyLadies Boston](https://www.meetup.com/PyLadies-Boston/) recently had a mock interview night and with that I offered to review resumes. I got a few takers, did some reviews, and now I have some thoughts.

1. If you are randomly switching fonts, please have a good reason for it. It is distracting (in a bad way) if you go from a serif to a sans serif for seemingly no reason.
2. If you are writing your job duties as a bullet-point list, please make sure each point is connected to itself. I can't seem to think of a great way to say that, but let me give an example. If one of your points is: Improved test coverage by 10%, organized tech talks, and implemented a code quality standard - then those should really be elaborated upon if possibly and definitely split into three separate points.
3. Make sure your resume reflects the skills of the job you are looking for. That doesn't mean that, if you have been a research scientist that now wants to be a full-time programmer, you have to ignore your past history. However, you do have to highlight different things. For example, how did you analyze a set of data? Did you use Python? What libraries did you use?
5. Along the same lines: If you are applying for your first programming job and don't have any related experience, you really need a projects section that lists the programming projects you have worked on and any open source you have done, along with descriptions. You know you can do the job, but if you don't put proof that you can code, the internal recruiter/HR person is going to throw your resume out.
5. For skills section: if you are including it, please make sure they are relevant! If you are applying for programming jobs, you do not need to include photoshop. Also, definitely do not include the Office Suite... familiarity with Office or similar software is assumed if you know how to use a computer (which is also assumed if you are applying for programming jobs).
6. White space is your friend! Definitely don't jam everything together. Separating out sections, careful use of bold fonts and color, and horizontal lines can really help draw the reader's attention to wherever you want it to go.

A resume is often the first look that many people have into your professional life, so you want it to represent you in the best way possible. If you have any questions, feel free to comment!

*This post originally appeared on [my personal blog](https://www.jenniferkonikowski.com/blog/2016/2/24/a-quick-post-about-resumes).*
Hi, I'm Carson Evans
Tags: introductions
Published: 2017-01-30 17:48:55

---
title: Hi, I'm Carson Evans
published: true
description: My introduction post
cover_image: 
tags: introductions
---

I have been coding for 20 years.

You can find me on Twitter as [@carsonevans](https://twitter.com/carsonevans) and on my blog [carsonevans.com](http://carsonevans.com)

I live in Fairfax County, Virginia, where my wife and I run a software development company called [Digital Ambit](http://digitalambit.com/)

Historically I have focused on web development and content management systems, sometimes with a commerce integration. Lately I have been more focused on data integrations and APIs. 

I can write in many languages and know several open source frameworks. I prefer PHP using Laravel for writing APIs or quick applications. I use Drupal for content based sites. When doing data integrations for enterprises I will often write services in C#. I have built sites in the .Net MVC when companies don't want to run PHP. I also know my way around several of the AWS services.

I hack on node.js and the many JavaScript front end frameworks that are out there when I am playing around. I try to attend local PHP, API, Drupal, and Node.js meetups whenever possible.

I would love a chance to work on node for an enterprise client but have yet to convince one of my existing ones to let me do so.
100% Coverage
Tags: testingcoverage
Published: 2017-01-30 17:44:04

---
title: 100% Coverage
published: true
description: Lessons learned when reached 100% code coverage
cover_image: 
tags: Testing Coverage
---

I accidentally reached 100% coverage. Before I had 90%+ and felt pretty confident. The coverage reports gave me useful insights about my own codebase and I understood deeply what's going on and where.

The last statement was a bit more difficult to test and I was pretty confident that it works. So I wrote the unit test only to learn how to test this kind of stuff… and I found out that there's a bug.

## What does it mean to have 100% test coverage

I always thought that it's about testing all lines of code. However, decent coverage reporter complains about missed else paths, so it actually also includes code which isn't there.

More accurate definition might be that all branches of code are executed during test run. Eg: for every if condition, there has to be at lest two unit tests (one for if clause, one for else clause).

The good thing is that you don't need a unit tests for 100% coverage. When you have a complex integration test which covers all cases, you might get most of your code tested.

## Is it worth it?

The most common counter argument is that the metric itself is useless, because some tests are more important that others. I agree with that, some parts of code are crucial and should be tested more than others (these parts of codebase I usually have at least 100% covered).

The point is that the number itself isn't important. Test coverage is great because it helps me to understand how the code is executed. It allows me discover edge cases I'm not aware of.

> The goal isn't to have 100% coverage, but rather understand 100% of the code and be aware what's going on there. Full code coverage is just a side-effect of such approach.

*Link to [original post](https://medium.com/@TomasEhrlich/100-coverage-3b82c108bbd8).*
Protocol oriented Programming (PoP)
Tags: code, designpattern, ios, iosdev
Published: 2018-04-11 06:53:02

---
title: Protocol oriented Programming (PoP)
published: true
tags: code,Design Pattern,iOS,iosdev
canonical_url: 
---

This post is a part of my blogpost series while learning Swift and Programming paradigms. [First part on Functional Programming can be found here](https://itscoderslife.wordpress.com/2016/12/10/what-is-functional-programming/).  
  
 **Protocol oriented programming (POP)** can be said as as – _a way to adhere the “ **Program to interface not to implement** ” principle_ – which is one of the basic design principles of software development. Structure your code such that you define interfaces first then make the classes implement it. Define interfaces using protocols and then make classes implement them. POP is just another technical term for the interface programming in Swift programming language.

Yes! There are additional advantages of POP in swift using “Extensions” along with protocols in Swift.

Let us discuss this with a classic example – **Shapes and its classes**.

Any shape has area. Every shape needs to be drawn on some canvas. Typically an average programmer thinks:

- Let’s have a base class named Shape.
- Let’s derive all other concrete classes from Shape class.

The first and foremost disadvantage of this solution is all concrete class inherits everything from base class whether its needed or not. Along with that multiple inheritance is not possible and moreover its a bad way.

In a practical world as the product grows its code grows and there will be a lot of overhead built over a period of time.

Here comes Protocol Oriented Programming – creating interfaces

This is link to Xcode [playground @ github](https://github.com/itsdamslife/DesignPatterns/blob/master/SwiftPlaygrounds/ProtocolOrientedProgramming.playground/Contents.swift) – giving a typical example of POP. Please go through the code before proceeding to understand the advantages.  
Some plus points of POP :

- **No overhead** of base class.
- **Protocol extensions** are a great way to give **default implementation**.
- Classes can **conform to multiple protocols** also use their default implementations without overhead of inheritance.
- Restrict access ONLY to specific functionalities of an object.
- **Protocols** can be conformed by **structures & enumerations**  in Swift. Class-Only protocols can also be defined
```
[protocol TheClassOnlyProtocol: class { ... }]
```

.

- Protocols can be used as a **type for variables** , which is more dynamic than declaring variables with concrete classes.
- **Delegation** works as it used to in Objective-C.
- Protocols can be used in **Collection types**
- A Protocol can inherit from multiple other protocols ( **multiple inheritance** )

This is my understanding of POP. Please do share your comments below.

Hope you found this post useful to some extent.
Hi, I'm Martin ModrÃ¡k
Tags: introductions
Published: 2017-01-30 14:43:33

---
title: Hi, I'm Martin ModrÃ¡k
published: true
description: An introduction post
cover_image: 
tags: introductions
---

I wrote my first program about 22 years ago and have been coding regularly since then.

You can find me on GitHub as [martinmodrak](https://github.com/martinmodrak)

I live in Prague, Czech Republic (that's in Europe ;-) ).

I work at the Czech Academy of Sciences as researcher/programmer.

I have biggest experience in Java, but I have switched projects and languages frequently. I thus also feel comfortable in C#, Python, C++ and recently Elm.

I am currently learning more about Elm, Rust and OpenCL.

Nice to meet you.
Don't document your code. Code your documentation.
Tags: softwaredevelopment, programming, cleancode, documentation
Published: 2017-01-25 22:02:08

---
title: Don't document your code. Code your documentation.
published: true
description: A lesson from the Clean Code book
cover_image: 
tags: software development, programming, clean code, documentation
---

This is one of the great discussions among developers: document or not document your code? Is it worth writing documentation in your code?

I thought this topic was completely overcome and it was clear that, except some few occasions (implementing a public API), documentation was not necessary. Until I saw a code review where the reviewer pointed out the lack of documentation as an issue. Really?

I was one of those who used to document my code... or at least I tried. I was so convinced that code had to be documented. As a backup or reminder for my future myself or any other developer luck enough to end up in my code. Although I always realised it was always out of date. And by then, I already wondered: what is the purpose of documenting the code if the documentation is always outdated?

Until several years ago I read the book [Clean Code](http://amzn.to/2jF9iQV).

I saw it "crystal clear", there is no need to document your code if you code your documentation.

With this I mean to use meaningful variable and method names. If the name of the member already tells you the information that is keeping and the name of the method tells you what the method is doing you can end up reading the code without the need to figure out or document what your code is doing.

Extract as much code as you can to methods. Even if you end up having a method with only 3 or 4 lines. Each method should do one thing and only one thing. And the name must explain what it does.

Each member of a class must have a name that only reading it you know which information you can find there. Same for variables and input parameters.

Following this simple steps you can have a code you can read, having the documentation right in the same code.

Yes, I know, there are those times you have to implement code with a complex algorithm or you are copying a code you found on Internet which might be complex, you might not understand and you might not extract in simple and meaningful methods. Yes, there are always exception.

What do you think? Do you document or write the documentation in your code?

*This post was originally published in [Medium](https://medium.com/@morillas/dont-document-your-code-code-your-documentation-5b940357a829)*
Hi, I'm Berkus Decker
Tags: introductions
Published: 2017-01-30 08:54:59

---
title: Hi, I'm Berkus Decker
published: true
description: My introduction post
cover_image: https://thepracticaldev.s3.amazonaws.com/i/zbnazpgzkj46mtvdsc69.jpg
tags: introductions
---

I have been coding for 20+ years.

You can find me on GitHub as [berkus](https://github.com/berkus)

I live in Tallinn.

I work for Twilio.

I mostly program in these languages: C++, Rust, Kotlin.

I am currently learning more about capability-based access control.

Nice to meet you.
Hi, I'm Gary Sieling
Tags: introductions
Published: 2017-01-30 01:58:40

---
title: Hi, I'm Gary Sieling
published: true
description: My introduction post
cover_image: 
tags: introductions
---

I have been coding for 17+ years.

You can find me on GitHub as [garysieling](https://github.com/garysieling)

I live in PA.

I work for Wingspan Technology.

I mostly program in these languages: Scala, Javascript, Java, Python, and SQL.

I am currently learning more about machine learning.

Nice to meet you.
Hi, I'm Glen Pierce
Tags: introductions
Published: 2017-01-29 21:38:58

---
title: Hi, I'm Glen Pierce
published: true
description: My introduction post
cover_image: 
tags: introductions
---

I have been coding for ifYouOnlyCountApplicationDevelopment ? 2 : 13 years.

You can find me on GitHub as [glenpierce](https://github.com/glenpierce)

I live in Vancouver.

I work for Jostle

I mostly program in these languages: Java, JavaScript, HTML, CSS, SQL, and a little C#.

I am currently learning more about Node.js, Neural Networks, various game engines, I'd like to get better at 3D rendering.

Nice to meet you.
Hi, I'm Bojan Veljanovski
Tags: introductions
Published: 2017-01-29 20:27:54

---
title: Hi, I'm Bojan Veljanovski
published: true
description: My introduction post
cover_image: 
tags: introductions
---

I have been coding for [number] years.

You can find me on GitHub as [bojanv91](https://github.com/bojanv91)

I live in [city].

I work for [company]

I mostly program in these languages: [languages].

I am currently learning more about [topic].

Nice to meet you.
Hi, I'm (((Joe Knee)))
Tags: introductions
Published: 2017-01-27 20:16:29

---
title: Hi, I'm (((Joe Knee)))
published: true
description: My introduction post
cover_image: 
tags: introductions
---

I have been coding for [number] years.

You can find me on Twitter as [@j0ni](https://twitter.com/j0ni)

I live in [city].

I work for [company]

I mostly program in these languages: [languages].

I am currently learning more about [topic].

Nice to meet you.
Hi, I'm Paul Gier
Tags: introductions
Published: 2017-01-27 17:03:18

---
title: Hi, I'm Paul Gier
published: true
description: My introduction post
cover_image: 
tags: introductions
---

I have been coding for [number] years.

You can find me on GitHub as [pgier](https://github.com/pgier)

I live in [city].

I work for [company]

I mostly program in these languages: [languages].

I am currently learning more about [topic].

Nice to meet you.
Hello!
Tags: introductions
Published: 2017-01-26 21:15:21

---
title: Hello!
published: true
description: Intro post
cover_image: 
tags: introductions
---

I have been coding for 15 years, 5 years professionally.

You can find me on GitHub or Twitter as [@vermiculus](https://github.com/vermiculus)/[@vermiculus](https://twitter.com/vermiculus)

I live in Madison, Wisconsin and work for Epic making healthcare software.

I mostly program in C and various Lisps.  For work, I use M and VB6 almost exclusively.  (It's really not bad!)

I am currently learning more about writing my own dialect of Lisp to use at work using the [Make-a-Lisp process](https://github.com/kanaka/mal/blob/master/process/guide.md) as my guide.

I'll probably be using this medium for a while until I can find the time to get [my own domain](www.seanallred.com) back up and running.
My personal take on TDD
Tags: 100daysofcode, testing, tdd
Published: 2017-01-26 07:45:13

---
title: My personal take on TDD
published: true
description: 
cover_image: 
tags: 100daysofcode,testing,tdd
---
I'm going to start out saying something that will upset people. I don't personally think TDD works well for Unit Testing.

Now, don't get me wrong, TDD works fantastically for some people. And I personally find it works really well at a larger scale. But when it comes to writing Unit Tests, I find that writing the tests first just doesn't work as well.

This might be a side effect of my Java background (static typing, compiled language means that you can't write unit tests really until you've got something to test) 

When it comes to Acceptance Testing however, I think that TDD is a great tool.

So, what's the difference?

At the Unit Testing level, you are generally not writing a single unit of code in one go. You will often find that you are writing several different pieces of code that all work together, and the design of these different pieces is fairly fluid whilst you are developing them. Writing the tests for these pieces of code is - for me - counterintuitive.

On the other hand, at the Acceptance Testing level you hopefully have a decent idea of what you are writing and how it is going to work. Whether this is the UI/UX, or the REST API, or whatever the external interface to all of this is, you should know how this part of it works before the tests are written. You should therefore know what you are testing and how it will work ahead of development, which means that you *can* write the tests for it first.

So, for me personally, TDD doesn't work well for Unit Testing.
Hi, I'm jlongo62
Tags: introductions
Published: 2017-01-25 21:33:58

---
title: Hi, I'm jlongo62
published: true
description: My introduction post
cover_image: 
tags: introductions
---

I have been coding for [number] years.

You can find me on GitHub as [jlongo62](https://github.com/jlongo62)

I live in [city].

I work for [company]

I mostly program in these languages: [languages].

I am currently learning more about [topic].

Nice to meet you.
Hi, I'm Samuel Lindblom
Tags: introductions
Published: 2017-01-25 11:41:29

---
title: Hi, I'm Samuel Lindblom
published: true
description: My introduction post
cover_image: 
tags: introductions
---

I have been coding for 8 years.

You can find me on GitHub as [rutinerad](https://github.com/rutinerad)

I live in Mariehamn, where I work in the gaming industry.

I mostly program in these languages: JS, Java, PHP, Python.

I am currently learning more about Microservices.

Nice to meet you.
Hi, I'm Rashidi Zin
Tags: introductions
Published: 2017-01-25 06:08:57

---
title: Hi, I'm Rashidi Zin
published: true
description: My introduction post
cover_image: 
tags: introductions
---

I have been coding for 9 years.

You can find me on GitHub as [rashidi](https://github.com/rashidi)

I live in Kuala Lumpur, Malaysia.

I work for GfK

I mostly program in these languages: java.

I am currently learning more about spring boot, angularJS.

Nice to meet you.