Welcome to this week’s Friday with Filip!
There’s a saying that goes like this:
Use the right tool for the right job
Even if you find the right tool for your job, do you know how to use the tool correctly?
This is exactly what I want to talk about this Friday; you need to know your tools in order for you to know it’s the right tool for this job!
Do you know your tooling?
All too often I see developers using amazing new tools but in many cases not knowing the limits or how to use it correctly. It’s very important to understand how to use a tool and what the implications of using a tool in a certain way has. When I find a new tool or a new library that I want to use, I try to research it and understand it before I recommend it for production use.
To me a tool is not only a software that I run or a hammer that I use, but I also consider a third party library a tool. A tool for me is something that I use to solve a certain problem and smaller parts can build a larger tool.
Problems with not knowing your tools
If you don’t know what your tool does behind the scenes you can get very big problems in the end. If you try to use a hammer to screw something into the wall there might be an easy work around just to hammer the screw into the wall. But what if it was the other way around?
Imagine that you had a screwdriver but a nail that you had to put into a plank; getting that into the plank would be much harder, no?
It’s still possible of course to solve the problem by just using the other end of the screwdriver and hammer the nail slowly into the plank.
So where am I going with this?
If you use a library or software that is new and hype which solves a certain problem but makes it harder for you; maybe you’re doing it wrong! The tooling might be great for solving one of the problems, but the way that you use it just gives you too much of a headache. If you go back and do some research on the tools, you might find that you are using it wrong or that the tool simply is not for the specific use case.
A good example here is LINQ to EF. I’ve seen many developers knowing how to use LINQ but not knowing what happens behind the scenes. This can be very dangerous for the performance of your application.
One other problem that arises with this is that most of us test our applications with very little data in it, but in a real world application after some time there might be a lot more data to process which was not considered at the beginning.
Now to be a bit more concrete, see of the following LINQ to EF query:
var persons = from person in db.Persons
where person.Name.Contains("Filip")
select person;
This can of course be written like this as well:
var persons = db.Persons.Where(person => person.Name.Contains("Filip");
Both of these will be executed as soon as you request the result by doing persons.ToList(); for instance.
This all looks very good, it might be exactly what we want to do as well. But what happens if we have 1 billion persons in our database?
The SQL query that is generated from this will perform what is called a row search, which means it does not use any indexing which means it will have to go over 1 billion persons and do a search within each person’s name.
Consider that it generated the following SQL:
SELECT * FROM Persons WHERE Name LIKE '%Filip%';
Of course we can optimize this by using full text search! But that is not the point, the point is that we might not have considered that Contains() will actually be a slow operation to run. If we knew that this would skip all indexes we might had chosen to use StartsWith() instead.
Another problem with not knowing how LINQ works internally is that all too often I see developers doing ToList() just because they want to use the types in .NET instead of having it translated to SQL. If they had known of EntityFunctions or SqlFunctions they might had chosen to run the query on the database side instead of doing LINQ to Object!
Because if we perform the query below, we will actually fetch the 1 billion rows from the database and have them in memory and then perform the search in the application instead.
db.Persons.ToList().Where(person => person.Name.StartsWith("Filip").ToList();
Again, if we know our tooling and use the right tool for the right job, we are going to do a much better job.
Do you know your tools?
Vote on HN
Welcome to this week’s Friday with Filip!
Last week I shared the first part in a very interesting session that I had the pleasure to do with Patrick over at NDepend. Having readable code and manageable solutions is very important but in some cases small changes that might see, trivial to you, might not be as trivial to someone else.
If you had to keep track of all dependencies in your head you are not going to have anything else on your mind; which is a pretty bad way to distribute your brain! Instead of keeping it all in your head, you can use a tool like NDepend to find out a lot of interesting things about your projects. If you’ve seen the previous posts and videos that I have done on NDepend, you know what kind of power this tool delivers.
The webinars that I have had the pleasure to do with Patrick has been very educating and I hope you like them as well, I would love to get some feedback!
So this week we are going to dig deeper with NDepend and spot dependencies, dependency cycles and spaghetti code! As we look on mscorlib, you can see that in some cases bi-directional dependencies are by design, but in other cases it might have been accidental. Sit back and enjoy the two parts below!
Part 2
Keeping our code base clean and understandable is important and as you might have seen now, there are tools that can help us along the way.
What are your tips on the subject?
Vote on HN
Welcome to this week’s Friday with Filip!
Two weeks ago we looked at Dealing with Code Complexity using NDepend. This was the first episode in the webinar series on Code Quality.
This week I am happy to share that Patrick Smacchia and I have recorded the second episode! This week it’s about dependencies, dependency cycles and spaghetti code. I really enjoyed doing these sessions with Patrick and I really hope you will enjoy it just as much. Let me know what you think of it!
Vote on HN
Welcome to this week’s Friday with Filip!
During the Fridays with Filip we’ve looked at how to ensure that certain parts of your project conforms to a high standard. I’m talking about the following:
There are so much more things (even small things) that matter when you want a successful high quality project/solution. You can’t rely on a decent testing strategy, security awareness and rapid development to get high quality. There’s still a lot of other aspects in your project that you need to take into consideration.
When I studied for my Software Engineering degree there was a lot of talk about requirements documentation, design documents and all other kinds of documents that you had to write in order to get a good overview of the project. But there were actually less talk about how to retrieve this information.
One of the first things you’ll learn when talking about domain driven design is: use a language that both you and your customer understands. In order to get all requirements or the system design onto paper, you need to understand each other. Do you see where I’m getting at? We need to step back to the basics, to things that was important even before computers and software projects; we need to be able to talk to each other so that everyone understands!
Previously this week I asked something a bit weird on twitter as you can see in the image below.
At a glance, this might be a very weird question. Why would you explain something that is so far away from their reality? Someone responded and said that they would just not do it because they would probably be killed for knowing too much.
Technology is amazing and as a Software Engineer with a burning heart for programming I tend to try (almost) everything new that arrives to the market but not everyone do and this is very important not to forget. Since not everyone is so used to technology, we need to work on the way that we communicate with each other. A couple of years back I built a website that had to do with cars and the people that wanted the website had no idea how the process of building a website looked. So I had to use analogies they understood, I had to talk in car terms.
Therefore it’s very important to actually step back and find a common ground between you and your customer. Otherwise it will be near to impossible to deliver high quality; you’ll never get the right requirements!
As I said in the start of this there’s not one or even 5 things that will ensure you deliver high quality, you need to work on all different aspects. Here are some concrete suggestions (that might seem obvious):
- Find a common ground between you and your customer so that you speak the same language
- Design the architecture in a way that you could talk about objects and structure in the application which the customer understands
- Use the right person for the right job!
- Write lots of documentation before, during and after the delivery
- Have small iterations in the beginning where you continuously deliver parts of the system for reviewing
- Do code reviews, swap people around and let everyone review everyone
- Don’t be afraid to ask your customer questions if you don’t understand
- Don’t be afraid to ask you colleges for help if you’re stuck!
- Don’t get used to putting work off by writing TODO’s in the code
- Take a couple of seconds to write a comment about a method or a complex code block
- Remember that we’re all human, everyone can make mistakes; help each other out and solve them together
- Stay on top of new/old technology and use what is best for the project/customer. If a newer framework or tool means more job, maybe it’s the wrong tooling for this job; even if you want to play with the latest toys
This list can go on and on, frankly there have been books heavier than my laptop written about each point in the list.
What’s your pro tip to increase quality in the code, project and customer communication?
Vote on HN
Welcome to this week’s Friday with Filip!
Yet another interesting week has passed with lots of things to discuss. Before we dig into this week’s subject, I just want to take a brief moment to share something interesting that I found (it was recommended by someone I know from IRC). There’s a hosting company called EDIS based in Austria that is now providing a very neat service; Raspberry Pi Colocation! As soon as I saw this I shared it with HackerNews and got a response from EDIS on twitter:
It’s worth just thinking about this for a second, let’s say that 1000 RPi’s could host some websites, instead of 1000 1U rack servers; imagine the power that would be saved (and the space).
Now to this week’s subject!
Last week we discussed how we could join new projects and do that efficiently and I got some great tips & tricks from a lot of you (in different channels). This week we are going to follow in those footsteps and see how we can actually find complex code in our applications. While finding complex code is important for all different programming environments; we’re going to look at this by using C#, Visual Studio 2012 and NDepend.
It’s a little bit different this week..
I recently recorded the first episode of a webinar series with Patrick Smacchia, the founder of NDepend and who better to talk about Code Quality and Code Complexity than with him? So this week, I’m happy to announce that you can watch the first video in this webinar series!
It’s a 30 minute webinar where Patrick and I talk about Code Quality, Code Complexity (CyclomaticComplexity) and other things around this subject.
After watching the video, please tell me and Patrick what you thought about the video and tell me what your tips are to find complexity in your code or projects!
P.S. Today is the last day to get a 35%
discount on C# Smorgasbord!
Vote on HN
Welcome to this week’s Friday with Filip!
The last three Fridays we’ve looked at how to become more productive, how to increase security in your web applications and how to adapt to a real testing strategy. This week I want to talk about how I get deep into the new projects that I join, fast. The projects that I’m referring to are those that have been developed on before. The customer never really wants to pay for you to spend too much time learning the code base and the actual project, so you’ll have to use tools that will help you do so fast.
What I do when I first get the project on my table
The first thing that I obviously try to do, is get the project running or get all the tests to give me green lights. This assumes of course that there are tests written for the system! Just imagine that you need to join a project that has been developed for hundreds or thousands of hours and there’s no tests and no documentation; this is much more common than you might think. That’s why the following quote is what everyone should be feeling when writing code.
Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.
As soon as I’ve gotten the project running, or the tests are all OK. I can move on to understanding the code base. Normally when you get a project on your hands, there’s something that is needed to be done, let’s say that you need to implement a feature.
The first thing that I try to do, is get an overview of the complexity and what is depending on what. To do this, I’m using NDepend (which I’ve written about in C# Smorgasbord). NDepend will give you great reports and help you find complexity in many forms. Here’s an overview that shows what is connected to what and the size of the boxes indicate the complexity:
When I find something that I think is too complex, I try to identify if there’s a test for that by analyzing the code coverage. If the code coverage is bad, I try to start writing some tests, this will help me get custom to the project. I don’t worry too much if the tests fail; this means that I need to debug the tests which will force me to step into the complex parts of the system and analyze them further.
To get a great overview of my testing, I use the built in (not in VS2010 Express versions, but in VS2012!) MS Test tooling.
Break & Fix the code
When I’ve come as far as starting to write tests for complex parts that are already in the system; I try to refactor small parts, break stuff to understand the business logic. This all helps me get a great idea of what the particular parts do.
In order to help me get an idea of what is covered by tests and not when browsing around the code, I use NCrunch. NCrunch is great, I configure it to add black dots everywhere to indicate statements that are not covered by tests. Then when they are tested, the dots go green and this is updated in real time!
At this time I can normally start looking at the actual task that I need to perform. Depending on how large the project is and how complex it is, the above process might be short or long. But at least for me, it’s a great way to get my head in a new project.
tl;dr
So you’ve got a new project that you need to implement features in, here’s what I recommend:
- Analyze the complexity of the code with tools such as NDepend
- Write tests for un-covered code to understand the flow of the application
- Use NCrunch to annoy yourself with black dots so that you’ll write more tests and get a better knowledge of the code base
- Break the code and fix it again — then refactor!
What are you doing to spend less time understanding a system and more time actually fixing the problems?
Vote on HN
Welcome to this week’s Friday with Filip!
Earlier this week I wrote about how to organize your thoughts by using tools such as Evernote and XMind. Both of these are very easy to work with but are somewhat limited to getting your thoughts into a persistent format. Since productivity is important to all of us, I wanted to spend this Friday on exploring more tools that can be of great use to primarily developers. We live in an era where everything needs to be done as quickly as possible, with the highest quality and costs as little as possible. This can pose as a problem in many cases because they don’t quite fit that well together.
In my previous article, Let’s write better software, I discuss how we’ve been entering a world with more and more hardware and software; whereas bugs are more an expectation than an exception. This is of course a big problem, since we all want bug-free world. As many have pointed out though, the biggest problem are the people that are unwilling to pay for quality; of course, that’s not the way it’s sold. In many cases it’s either getting the contract or not getting the contract which can lead to doing the same thing within a more narrow time period.
Before this get’s out of topic, let me explain why this is about productivity. When we need to do something faster but still maintain the same amount of quality. We need tools to help us with analysis, suggestions and in programming we want help with refactoring. Without such tools, we would be less productive. This expands over many areas, not only development.
The right tool for the right job
This week I want to be more concrete and give hands on examples on what tools that I use in my day-to-day work environment. Feel free to leave suggestions on what productivity tools that work best for you and for your team.
There are a couple of areas where I try to be as productive as possible (of course I always want to be productive!):
- When I’m in a meetings
- When I’m coding
- When I follow up on a bug
As I stated in my previous post organize your thoughts, I use some tools to get my thoughts down quickly. But it is also important when you’re meeting with a customer or a college and a bug is presented, this needs to be documented in a good way.
I’ve been using Pivotal Tracker for a while now and I like it; I would however like to give TFS 2012 a fair chance.
Pivotal Tracker allows us to track development, bugs, ideas and both give the project members and the customer a great overview of the project progress. This together with Evernote and XMind is very powerful and gives me a total set of powerful applications to use in a meeting.
Another tool that I like to use, which makes my understanding of a system better, is balsamiq mockup. This mockup tool lets you create nice overviews of how the UI will look when the system is done. When you’re brainstorming with your customer around what the UI will look like, this is a very productive tool to have in your collection.
When we’re done with a mockup, we can simply save it on the corresponding bug, task, feature or idea in Pivotal Tracker.
When I’m coding it’s very important to me that my tools are not in the way of my development. For instance, I don’t want a lot of non-natural keystrokes or popups to use. I’ve been swapping between ReSharper and JustCode.
When using ReSharper I get a lot of nice instant feedback on what I can do to improve my code, this makes it easier if someone is going to review the code at a later stage:
JustCode supplies the same amount of keyboard mappings, analysis and refactoring capabilities but one other thing that it provides is a way to stick a cheat-sheet on your desktop. This makes it very productive when I need to get use to some keyboard shortcut:
If you want to code productively, here are some recommendations:
- Spend a while analyzing what keyboard shortcuts your IDE provides
- Use productivity tools such as ReSharper and JustCode
- If you’re using Visual Studio, learn how to use Snippets
- Use a source control that is not in your way
These might seem obvious, but adapting to these sure helps me being productive. If I can solve a problem faster with just as much quality, I can spend the additional time that I just won on making the solution better.
What are your recommendations on being productive?
Vote on HN
I was once put in a project where a lot of the architecture and development was already in place. Immediately when I started working with the project I gave the other team members my thoughts on improvements, some of them regarding testing and some of the regarding security. Last week we focused on the testing, so this week, let us talk a little bit about security.
One of the biggest concerns I had about this project was that usernames and passwords were stored in clear text; this gave me the shivers. I talked to my team members and everyone agreed that this was Very bad. I have no idea why someone would design a login system with username and password where the information is stored in clear text. Or even in a way where passwords where stored in anything else than a hash.
But before I could change this, I had to get a go from the customer to put a couple of hours on changing everything in the system. When doing so, something scary happened. I got this response from our customer:
Don’t put any time on security, we’re going to get hacked anyways and that means free media.
When you hear something like that, it’s obvious the person does not know a lot about IT security or marketing in general. Assuming that the system would get a lot of media slots because of a major leak, the cost to get your reputation up again would be much greater than what it would have been if you just invested in security to start with.
Have you ever experienced something like this as well?
A lot of systems get hacked quite often, but when they do get hacked, it’s pretty darn important that customer data is intact and not easily accessible.
Design your system assuming that you will be attacked by hackers. I think this is quite important, don’t assume that hackers won’t care about you. I would even advise paying a good hacker to test your security to find vulnerabilities.
Revise your web security
Always take time to think about security, do it rather sooner than later. When you do think about security, it can be quite nice to fall back on some best practices or rather a check-list of common things that developers do wrong.
To help us all out with this, there’s a project called “The Open Web Application Security Project“. This project has a Top 10 list of most common security problems on web sites. Here’s the list:
- Injection
- Cross-Site Scripting (XSS)
- Broken Authentication and Session Management
- Insecure Direct Object References
- Cross-Site Request Forgery (CSRF)
- Security Misconfiguration
- Insecure Cryptographic Storage
- Failure to Restrict URL Access
- Insufficient Transport Layer Protection
- Unvalidated Redirects and Forwards
Follow the OWASP Top 10 list, ensure that your application is tested against each item in the list above. This is at least one step in the right direction.
Security is often a sensitive subject, but I find that most most organizations that don’t want to dicuss security don’t think that they have a secure enough system; transparency is key.
Is security a key when you develop applications and is your company transparent when it comes to security?
OWASP Top 10 is a good place to start, but it’s just the tip of the iceberg. If you have any stories to share regarding security or any tips & trix along the way, feel free to leave a comment!
Vote on HN
Welcome to Friday with Filip!
Wow, am I excited or what! I was out on a “developer lunch” in Gothenburg with some very nice people and we started talking about blogging, teaching and other fun stuff like that. We started discussing how I usually have what we call “CodeStar” at work; each Friday I teach my co-workers about something exciting for an hour or two. I’m not Always the guy doing the presentations, but mostly.
Anyways, we college who was also with me on this lunch referred to it as “Friday with Filip” and this started to grow on me. So with some great input from my college , Iris and Anton, I decided to create a blog series called Friday with Filip!
The idea is pretty simple, I want to give my point of view on a subject and then hopefully teach you something and start a discussion around it. Feel free to leave a comment or drop me an e-mail on mail [at] filipekberg [dot] se! All feedback is welcome!
If you like the idea, please share it with your friends by clicking the share button below.
Do you use a decent testing strategy?
I’m currently working on some very large projects with my company and it’s all very interesting. What I’ve found most exciting about these larger projects is that the testing strategies are much more important when it comes to these larger systems. Personally I think that testing is Always important and should be prioritized.
If we look at it all from the customer perspective, how can they be ensured that things work accordingly if there is no documentation to back it up?
I don’t know about you, but I’ve heard the following excuse to why test reports are sometimes neglected:
We don’t need to do any advance testing, this system isn’t going to be that big.
Stop all these excuses! In my book I talk about how we can use unit testing to ensure that certain parts in a system work correctly, but this is just a fraction of everything that needs to be tested. Many things that we do, we test manually. If we wrote a couple of lines of text each time we did a test, it would surely take a couple of more minutes on each requirement, but it’s going to be worth it in the end!
You don’t really need to put so much effort into making a nice test document. Open up word and just add the information that you think would be valuable if you were looking on the system from the outside.
When you deliver your product, don’t you want to feel like you have a large pile of documents backing up your quality?
Here’s what I would want to have in a perfect programming world:
- Write unit tests whenever it is suitable
- Automate as many manual UI tests as possible
- Document the tests and not leaving out anything even if it fails!
I recently set up a fairly simple test report document that just includes this:
- Test name
- A reference to the Use case / Requirement (of available)
- Description of the test
- Expected result
- Actual result
- Actions needed to mark the test as complete
When you assemble all these in a large document and give to your customer with a sprint delivery, you can surely feel better about yourself! Here is a word document that I put together for this, you can use it as you please. Let me know if you like it.
What is your testing strategy, if you have any? If you don’t, how would you like it to be?
Don’t forget to leave a comment or drop me an e-mail, thanks for reading the first Friday with Filip!
Vote on HN
Filip Ekberg is a Senior Software Engineer working in the country with all the polar bears, author of a self-published C# programming book and overall in love with programming.
