Web Development & Web Design Blog http://blog.designpuddle.com
Web Dev News, Articles, Inspirations, Ideas, Instructions & TutorialsThu, 28 Mar 2019 12:14:26 +0000enhourly1https://wordpress.org/?v=5.0.3https://i1.wp.com/blog.designpuddle.com/wp-content/uploads/2015/11/cropped-dpnew-2.png?fit=32%2C32Web Development & Web Design Blog http://blog.designpuddle.com
3232108331886Any questions?http://blog.designpuddle.com/web-development/do-you-have-any-questions/
http://blog.designpuddle.com/web-development/do-you-have-any-questions/#respondMon, 18 Mar 2019 09:40:07 +0000http://blog.designpuddle.com/?p=1299It’s the end of a presentation and those famous words are spoken once again, having heard this numerous times, very often the speaker/you are met with silence. You’ve just spent a week, perhaps longer preparing a presentation, a post or a new tool for people to use, and nobody has any questions about what you’ve just displayed! Faces are blank, and people make a swift exit. Why is this?

It’s because you’re doing it wrong!

What do I mean by that? Let me explain.

When you bring people into a room and tell them something new, they may be excited and intrigued, but first they’ll feel doubtful, confused and defensive. You don’t want to sound silly saying something that doesn’t make sense, and makes you look bad, so most people say nothing at all.

How can we disarm the audience?

As our instincts are always on alert for dangers or threats, we’re predisposed to be wary of change. Making sure your audience is relaxed and comfortable is an important first step. Throughout your talk, you will need to coax the audience into small acts of participation. Have you ever noticed, that once someone has spoken up during a presentation, they are inclined to speak up again further down the line, this is not a coincidence, it’s the participant becoming accustomed to the speaker and feeling safe and satisfied with how the last exchange went.

To get people to speak up you will need to follow a set of rules that will help that happen.

Susan describes the best presentation she’s been to, it was actually a performance by musician Bobby McFerrin; a master of music and in particular extensive audience participation. He does this by bonding the group and taking it slow. Sitting in a room full of strangers you won’t want to look silly, but Bobby starts by getting you to sing a single note, he then builds upon that one act asking for a little more each time until everyone is freely participating. I’ve embedded a Ted talk showing him in action below.

Now I don’t expect you to go to these lengths to get the audience to participate with you, but there are some specific things that could help gain traction in future talks.

7 Things you can do to improve audience participation

Be sure to let the audience know early on that questions can be asked throughout, unless you specifically don’t want them this will improve engagement throughout the talk. Anyone that speaks up during the talk, will have a much higher probability of asking one afterward too.

Questions aren’t to be feared. They’re to be embraced. There’s no better way to connect with an audience than to allow them free rein to ask as many questions as they want.

Start slow, and try and get your group feeling safe. You can use humor to make people feel relaxed, but don’t make fun of people as a form of humor or they’ll start to feel unsafe.

Keep you hands open with palms up when asking questions, this means you’re asking for something from the audience. Subconsciously the audience will recognise this and help you out.

Ask the group to do one small activity before taking on anything more complex.

There’s a reason that ice breakers are so commonly used in group scenarios. When introducing a topic you could ask for a show of hands, or ask anyone if they are aware of what you will be defining. These little steps although minor will encourage people to be more vocal further down the line.

When you ask people to do stuff, use nouns rather than verbs. By invoking a sense of belonging to a group, people are much more likely to comply with your request. Gregory Walton has published a great study into this that you can read fully here.

Take this as an example.

When asking someone “How important is it to you to be a voter in tomorrow’s election?”rather than“How important is it to you to vote in tomorrow’s election?” , this simple phrase change was said to have had contributed an 11% increase into whether participants would actually vote!

So perhaps rather than asking, “Does anyone have any questions?” Try, “Do you have a question” or “What are your thoughts“? Speaking directly to the the individuals in the group?

Smile, Breathe and Relax! The audience can read your mood, and as such will be more open to you if you are feeling confident yourself.

Nobody likes asking the first question, so how about asking it yourself. Prepare a question, discussing something you have may have not covered fully to engage the audience, and make them less self-conscious about asking something that may be off topic.

Let us spin a positive light on this, most of us aren’t well versed in speaking to large groups of people. Whilst creating an interesting and engaging presentation is hard enough already, having to think about audience participation seems like an afterthought. Next time a presentation is looming, try using some of the tips noted above when preparing for your talk and see how this changes the engagement with that final question.

I’d love to hear of any great tips you may have, or any other books you know of that go into this topic further. Here are a few great posts I’ve found online, whilst writing this. Remember, being witty funny and getting the audience on board will get you a long way!

]]>http://blog.designpuddle.com/web-development/do-you-have-any-questions/feed/01299Why being a good programmer barely requires programming at all.http://blog.designpuddle.com/web-development/why-being-a-good-programmer-barely-requires-programming-at-all/
http://blog.designpuddle.com/web-development/why-being-a-good-programmer-barely-requires-programming-at-all/#respondMon, 18 Feb 2019 09:59:25 +0000http://blog.designpuddle.com/?p=1272Yes, you read that right. To be a good programmer you don’t need to be good at programming.

I hear what you’re thinking, that makes no sense! Well hold on a second, hear me out.

When you think of a good programmer you know, what’s the first trait that springs to your mind? Determined, smart, approachable? Calm, Quiet, or conscientious? Maybe it’s something else, but I can bet it wasn’t… a really good programmer. Why is that?

Programmers require lots of skills in their day to day jobs. The discipline no longer consists of sitting in a dark basement on your own thrashing out some code. In fact interpersonal skills are some of the most important a good programmer can have. Agile methodologies require lots of communication between different departments and individuals. You’ll be required to check in at least once a day, be available for planning, refinement, retros; constantly communicating about struggles, improvements and things that are going well.

The old days of getting your tasks and specifications up front, and being left to your own devices is long gone. You’ll probably be in contact with your users, asked difficult questions about your progress, and required to feed information back to your product owner/manager.

You’ll need to talk through your design with your superior and team as most likely you won’t be working on this on your own. Testers will be asking for updates, questioning whether your unit tests are credible and sufficient, your issue tracker will need to be constantly updated keeping discussions available for all to see.

You actually might be better off with a psychology degree then a computer science one to understand how to deal with all these different people.

So yeah, programming is gonna be needed at some point, but in general the stuff that 90% of us will be doing won’t require any revolutionary coding expertise.

In most cases the reason a project will fail is because requirements were not properly discussed and refined, or teams did not communicate properly about what was required from them. Rarely will it be because you weren’t a good enough coder.

Do you share the same views? Or do you think I’m talking nonsense, I’d love to hear your opinions below.

In this he mentions a term called Cargo Cult Programming and it really struck a chord with me.

I’ve recently joined a new company with a new programming language, new tools, new processes and a new team. Actually, it’s pretty much ‘new‘ everything.

This has caused me to do a lot of learning in recent months. Being relatively experienced, I like to look into the ‘whys’ rather than the ‘hows’ when learning new things. What I’ve realised is that this is not the most common approach.

When a user is tasked with adding to an existing codebase, extending the current solution, they will most probably check how this has been done previously, copying the approach for their solution. They may/will blindly follow this pattern as it’s how it’s been done before. Additional blocks get added on top of the tower, without questioning whether it’s the right thing to do. If everybody does this, this will eventually happen.

This is where the term ‘Cargo Cult Programming‘ comes from.

Wikipedia explains it like this:

Cargo cult programming is a style of computer programming characterized by the ritual inclusion of code or program structures that serve no real purpose. Cargo cult programming is typically symptomatic of a programmer not understanding either a bug they were attempting to solve or the apparent solution (compare shotgun debugging, deep magic).[1] The term cargo cult programmer may apply when an unskilled or novice computer programmer (or one inexperienced with the problem at hand) copies some program code from one place to another with little or no understanding of how it works or whether it is required in its new position.

Cargo cult programming can also refer to the practice of applying a design pattern or coding style blindly without understanding the reasons behind that design principle. Examples are adding unnecessary comments to self-explanatory code, overzealous adherence to the conventions of a specific programming paradigm, or adding deletion code for objects that garbage collection would have collected automatically.

A Common Problem?

Imagine a scenario where you’re working on a bug, finding the code that is causing the fault. You’re not massively sure what’s happening, so you;

Google the error.

You find a StackOverflow question.

Search for the most upticked answer.

Copy and paste the solution into your code.

Try debugging to see if that’s fixed your problem.

It has, so you check it in and move on.

Sound familiar?

Why do we do that? Why do we blindly take this snippet and use it as-is, in our implementation?

The use case is probably not the same, so I’d be surprised if the solutions was. Simple examples aside, understanding the reasoning behind the solution is more important than the solution itself. There are many things you can’t do with something you don’t understand. You can’t modify, improve or test it. You can’t document it and you can’t own it.

Tech Trends, Buzzwords & Microservices

We all love what’s new, and management especially seem to like following popular trends, keeping up with technological advancement.

Most teams will now follow an Agile approach. TDD and Automated Testing can be very useful in certain scenarios, Continuous Integration removes much of the overhead from the infrastructure team, Big Data and AI can vastly improve user satisfaction and Containerisation and most recently Microservices shift our old monolith architecture into smaller self contained services.

Each of these advancements is brilliant in its own right, and I don’t condone any of them. My predicament is whether we need to adopt all of them into all our processes and code? We see blog posts from Netflix, Facebook, Twitter showing how their use has transformed how they work. If big companies deem them necessary, should we not too? This is where cargo cult programming rears its ugly head again.

We need to understand the problems with our current designs, why they happened, and how they can be jettisoned away in the future. Yes, these new processes may help us with our problems, but blindly following them in the faint hope that they do is not the way forward, nor does it make any logical sense.

I mention Microservices specifically as a lot of companies seem to be making the transition, citing such benefits as:

Faster development time

High scalability

Easy to enhance

Ease of deployment

Autonomous teams with the freedom to choose technology

With a list like that, what’s there to think about? Let’s all jump on the bandwagon!

Wait a second… are there any drawbacks to this approach?

Architectural Complexity

In monolithic architectures, the complexity and the number of dependencies reside inside the code base, while in microservices architectures complexity moves to the interactions of the individual services that implement a specific domain

Operational Complexity

How to provision resources in a scalable and cost-efficient way

How to operate dozens or hundreds of microservice components effectively without multiplying efforts

How to deal with a lack of standards and heterogeneous environments that include different technologies and people with differing skill sets

How to deal with versioning

How to track and debug interactions across the whole system

How to keep track of hundreds of pipelines of code deployments and their interdependencies

These are lifted from Amazon’s own “Challenge of Microservices” whitepaper. Now I don’t know about you, but the drawbacks look a lot scarier to me than the benefits. Once again, I’m not saying this is not the right approach to go down, but unless these benefits outweigh the drawbacks what are you gaining from following this approach?

The ‘Public’ problem.

It’s simple really, Stop using the Public keyword, stop automatically creating Public classes. Why do we do it?

The problem with using the public keyword is you’re missing out on the benefits related to encapsulation. Why do we use it so much? It’s pretty much the default word we use when creating classes, all examples will use public classes, wizards and snippets will implement public classes. It’s time to stop. How many people have a public Facebook account? Most things in this world are private, as should our classes be. Make them private by default, and then if you need them to be public, change them then.

With great experience comes great apprehension.

The longer you are in a field, the less naive you are to perceived improvements that a new tool or process will bring. Most of today’s ideas come from decades old research into the field which are finally being embraced. Once something has gained mass adoption, it’s easier to feel comfortable with embracing it fully. That is, if it’s the right thing to do.

So feel free to keep on scouring the interwebs for solutions and tutorials to your problems; keep exploring new languages, frameworks and implementations. Just be aware of why they work, rather than simply how. We all learn from our own experiences and mistakes, so understanding the fundamentals will keep you from continuing down the same path in the future.

]]>http://blog.designpuddle.com/web-development/coding-concepts-cargo-cult-programming/feed/01216Are you an Incompetent Developer?http://blog.designpuddle.com/web-development/types-of-web-developers-the-incompetent/
http://blog.designpuddle.com/web-development/types-of-web-developers-the-incompetent/#respondMon, 03 Dec 2018 13:40:19 +0000http://blog.designpuddle.com/?p=1204Read More]]>One of the most interesting parts of software development, are the group dynamics that form to complete the task at hand.

This congregation of individuals compromise many different areas of expertise, personality and skill.

Neil Green has created this fantastic website describing these personality patterns that arise in software projects. The reasons these personalities exist, what effect they have on the projects and what can be done to rectify any problems that may arise. The one I want to discuss first is the Incompetent.

The Incompetent

The reason I wanted to focus on this first was that everyone feels that they know/ have known an Incompetent programmer.

Neil defines this personality as:

A Developer who lacks the intelligence or skill to do the job of writing software.

We know that we do not know what we do not know. That’s a bit of a mouthful, but in essence, we ourselves do not know our own level of incompetence!

Here are some questions that will usually get asked my groups of individuals.

How did this person get hired?

The interview process is not 100% foolproof, each organisation will allow people through that might not be up to your organisational standards.

Organisations and technology change over time, what may have been competent a few years ago may not be now. Developers need to constantly evolve, upskilling and training are integral to keeping on the competency curve!

Sometimes people are not good at teaching themselves new things.

These individuals are not stupid, they are highly educated people that may have been in the industry for a long time. They managed to navigate their way through the interview process and probably have all the qualifications that you would want and/or expect. However without guidance they cannot learn what they need to. When you no longer have a lecturer/mentor telling you what to learn and how to learn it, people can struggle.

Why is this person not fired?

There are a lot of legal implications firing someone! In certain cases, this can be fixed in other ways. The level of competence in any proficiency is not the only reason an individual is part of an organisation; Personality, Domain knowledge, Communication skills, being the boss’s nephew or niece!

This doesn’t mean there is any malice in their work, they simply do not possess the skills to adequately complete the task at hand!

What should be done now?

In most cases these individuals are not usually even detected, and if they are, most of the time they are just forgotten about. There may be several reasons why this has happened; Is there the guidance in the organisation to keep skills relevant? Have there been external influences that may have caused levels to decrease? Do these reasons change your perspective on the matter?

Don’t wait until the last possible minute to discuss performance, it’s best to be upfront about this as quickly as possible, otherwise it can get quite awkward. Is there a plan that can be put in place to improve?

All of us have innate talents, but few of us try and find out what they are.

The final straw, is trying to move this individual into another role that they are more suited to.

So… are you an Incompetent Developer?

Do you;

Blame your lack of productivity on a lack of company provided training?

Argue against technology, tools, and techniques that are “too complicated”

Greatly overestimate your work?

When asked for status on your progress, you are full of excuses and are often defensive?

Your features, once implemented are riddled with bugs?

If you have answered Yes that sounds familiar to a couple of these, then maybe you are on track to becoming an Incompetent developer! But don’t worry, once you’re aware of this, you can look at turning this around!

Software development is a high pressure job

In most cases, you will be working to improve areas in which you are not overly strong. You won’t do this if you do not know you have areas which you are not strong in.

You are most likely confident in saying that you are not good at certain sports, cooking or perhaps public speaking. If you ask yourself what you are not good at within your actual job parameters the answers are usually harder to comprehend. Learning your strengths and weaknesses will help you understand where to focus your energy, and hopefully you’ll turn it around before anyone notices…

You can then safely return back to your colleagues and talk about how incompetent that other person is again!

Thanks for reading, I hope this got you thinking! If you would like to share my opinion, please use the buttons below.

]]>http://blog.designpuddle.com/web-development/types-of-web-developers-the-incompetent/feed/01204A Hackathon Guide – What to do, How to do it & Who to do it with?http://blog.designpuddle.com/web-development/hackathon-what-how-who-guide/
http://blog.designpuddle.com/web-development/hackathon-what-how-who-guide/#respondWed, 28 Nov 2018 11:20:02 +0000http://blog.designpuddle.com/?p=1178Read More]]>

The goal of a hackathon is to create usable software or hardware with the goal of creating a functioning product by the end of the event.[2] Hackathons tend to have a specific focus, which can include the programming language used, the operating system, an application, an API, or the subject and the demographic group of the programmers. In other cases, there is no restriction on the type of software being created.

You’ve been summoned!

I was asked to participate in my first proper hackathon competition last week. You first get the announcement, then you need to decide whether you want to take part, what you want/can do and who the hell will do this with you? Here’s what I learned.

What do I do?

Once you’ve acclimatised to the idea, your next thought should be “what am I going to do?”

You need to take into consideration your strengths, the tools you know how to use, and things you know you can improve upon. Does your Hackathon have a theme? Or is it a more competitive based Coding challenge similar to HashCode, which I participated in back in early 2017.

What do you want to achieve?

Everyone will have different things they want to achieve from participating in a Hackathon:

Want to try out some new tech?

Have an idea to improve some existing functionality within your organisation?

Want to write a tool to help speed up development?

Want to understand team dynamics and the purpose of each department?

Like the idea of building something from the ground up?

You’re super competitive and want to win at all costs!

Maybe it’s all of the above. Maybe you don’t have an idea at all, and just want to expand your horizons and see what’s possible.

Pick something that interests you!

Whichever of the above has brought you to this process, make sure whatever you choose to focus on interests you. A Hackathon can be a long arduous process, and that drive that comes from something you have an attachment to will drive you through any barriers that will arise.

” Look for something that you see a problem with.“

Look for something that you see a problem with, then find a way of fixing it. Uber and Airbnb are good examples of taking something we already have and elevating it to another level using technology.

With the boom in AI Assistants, you could look at integrating Alexa, Google Assistant or Siri into an existing application. The fitness market and wearables introduce new data that can be used in useful and interesting ways.

GPS tracking and geofencing, automation, big data and the Internet of Things (IoT) are all areas that are still in their infancy and can yield impressive results.

Serverless systems, containerisation, and orchestration (K8) are going to become mainstream in the next decade, so how about chucking your code on AWS, Azure or Heroku? How about packaging your app using Docker, or changing your API approach to GraphQL?

Build or Implement?

You have two options when starting your idea, build on something that is already there, or start from scratch. There are many great frameworks out there that you can use, that will speed up your delivery. However, while creating something from scratch will require additional thought in each aspect, it will give you a higher level of personalisation and freedom.

“Don’t be afraid to re-invent the wheel”

Remember Angular was created by Google, React & GraphQL by Facebook, and Cassandra by Amazon to tackle problems that they had with Web Interfaces, APIs and Storage.

When is it?

The amount of time given to you to prepare will have an impact on what you can create. Going into a Hackathon without any prior preparation will put you on the backfoot. It does depend on your goals, though: maybe this event is a giant learning tool for you. Either way, coordinating where you have to get to, transportation, accommodation, and feeding yourself are equally important. You don’t want to be burnt out before starting!

Remember to sell your idea!

If your hackathon has an open structure allowing for different ideas, you may need to recruit others to your team. For that reason, you need to be able to sell your idea. Using the points above, figure out its purpose and make it sing. Remember at the end of the Hackathon you may need to present what you have done.

Towards the end of your allotted time, you may have a fantastic project created, however, unless you can showcase this, it will ultimately be a wasted endeavour. Marketing is not usually a strong point for many coders, so having the right mix of people in your team is imperative to your success. Even if, no formal presentation is required, documenting what you have done is important.

Get a good team together

A Hackathon on your own is possible, and maybe you just want a little time on your own to look at new things. In most cases though, having a good team will help you be more successful at reaching your objective.

Find people that are interested in your idea, or have interesting ideas of their own. Make sure you/they can and want to contribute to the team. When the team is together, find out your strengths and weaknesses and determine how tasks can be distributed.

Don’t be too optimistic: start simple, with something that can grow.

Rewriting the Google search engine or Facebook sounds great, however, try starting small. These products all started with minimal features that have expanded over time. If you can compartmentalize your idea starting with the fundamentals, then add stretch goals to improve, if you have time.

Trust me, even the simplest idea will present challenges you did not expect. Look at this as a Kickstarter, where you have tiers you want to achieve!

Showcasing your creation is imperative

Time to sell it! You’ve determined the best points about your idea, and what its purpose is, so now you need to showcase it.

How are you going to do this;

Do a live demo?

Give a presentation

Create a brief video

Write up strong documentation?

You need to figure out which one of these will show your hack in the best light. If it’s not fully functioning, showing mockups or wireframes can portray the missing link which you did not have time to complete without negatively impacting what has been achieved.

Collaboration

It is unlikely you will all be working on a single machine (you may not even be in the same room!) so looking at ways of collaborating on your idea will affect your efficiency.

Git has become the de facto code sharing tool, so if you haven’t used it before, getting to grips with it before the Hackathon is a good idea. Here’s a complete set of tutorials to get you on your way: https://www.atlassian.com/git/tutorials

Slack, Skype, Messenger, and Whatsapp are all good methods of communication. It depends on whether you want to be on voice comms, share your screen, etc.

Ultimately, Try and have fun!

By far, the most important advice I can give is to try and enjoy the Hackathon experience.

When finished, you may not even have a functioning product, so enjoying the journey and what you’ve learned will be the thing you take away from this.

You may be wondering how my attempt went? Well, unfortunately, our team didn’t win, but we created a really powerful tool which I’m ultimately very satisfied with.

It was a code generator that produced some boilerplate code required for our internal processes to work, I’d have shared the code, but it’s within a private repo with sensitive information. We used Node and a few packages to build and populate the templates required.

I learned a lot across our brief Hackathon window. Viewing all the different ideas and implementations that were created by others, really emphasised the breadth of creativity that our industry can produce. It also gave a great insight into what is possible to create in such a brief period and the camaraderie that can be built up over such a short time frame.

But most importantly, I had fun doing it!

If you have any other questions about the above, or want to ask further into what we did, please comment below. If this post helped you, please Share it too!

Appendix

]]>http://blog.designpuddle.com/web-development/hackathon-what-how-who-guide/feed/01178Code Review Checklisthttp://blog.designpuddle.com/web-development/code-review-checklist/
http://blog.designpuddle.com/web-development/code-review-checklist/#respondFri, 19 Oct 2018 08:46:52 +0000http://blog.designpuddle.com/?p=1141Read More]]>Code reviews are necessary to ensure your application is consistent. We live in an age of copy-and-paste craftsmen, so making sure that the bits that do get copied are correct is imperative for this approach to keep on working!

There are many articles out there telling you why code reviews are important, why you should use them, and how they will improve X, Y & Z. Most of us will already be familiar with the concept, practising it regularly (GitHub Pull Requests I’m looking at you!). This article is a simple checklist / cheatsheet. I may even create a nice infographic for it if it’s of use!?!

Having to complete these most days, it’s nice to have a checklist to follow, so you don’t miss anything. (You usually miss something).

— This is not a How To guide! —

I’m not going to say how you should find something positive to say, or how you help improve your team through this process, this will focus on what points to review.

Alternatively this can be given to developers as a reference, pointing out that these things will be checked, so make sure you are happy with them before we start.

It’s always important to have a framework to follow, the most annoying things are inconsistencies between reviewers, or focusing on irrelevant aspects. Try creating one yourself, you might even be able to base it off the list below! Let’s get stuck in.

Magic Numbers and Hardcoded Values

for (i=0; i<26;i++){

26 sure, that makes sense! How about we give that Magic Number a variable, so we understand what we’re doing? Something more akin to.

int AlphabetCharacter = 26;
for (i=0; i<AlphabetCharacter ;i++){

But even this can potentially be bad, what happens if another character gets added? We should really try and make this dynamic, and then use .size() or .length() on this object.

Code Duplication

Some people will know this as D.R.Y, but in all honesty it’s just looking for copies of code doing the same thing elsewhere. These should be refactored into their own method, easy. 2 blocks doing similar things might be allowable, but 3 or more is a definitive red cross from me!

Null Checks aka Defensive Code

Defensive code isn’t particularly fun to right, or pretty, and when things work it seems like it’s not even needed. However all to often on new implementations, when there is no data and we start running these methods things break!

if(objectYouAreCurrentlyTryingToDoSomethingWith != null){

Before accessing variables within objects and collections make sure they are there! PLEASE!

Variable Names

I suppose this goes hand in hand with magic numbers, if you need to create a variable for a value, then make sure you name your variables as simply as possible. If that variable is a constant or won’t be changed then use the Const keyword in applicable languages and the CAPITALISATION convention to let users aware of your decisions about them. There are lots of articles about this variable naming, but it’s really just remembering these basics.

Functions / Methods / Services

– Names

The name of a method is more important than we give it credit for, when a method changes so should its name. The most infuriating thing is a method called Save(), when in reality it actually parses, validates, speaks to some third party, retrieves other records and adds them to global variables and maybe, hopefully finally saves the record in question. Yes it’s doing a save, but that other stuff is important too, and should probably be communicated to the developer when they are calling it.

– Return Types

Make sure you are returning the right thing, trying to make it as generic as possible. Sometimes you don’t even need a return type. If you do use the Void return type then please be aware that Void should do something, not change something!

– Access

Private vs Public, this is a big topic, and once again there are lots of good articles out there on it. It’s mainly about securing your application, making sure that certain procedures cannot be called outside of a class. Some people argue to make everything private until you need to make it public, however I find that making something private on purpose means more, and specifically tells a fellow developer that this is not to be used outside of the class. It’s not usually too costly if missed, but keeping an eye of the access level of a method can stop issues further down the line, where internal logic now cannot be changed because others have used it for other purposes.

Unit Tests

Simple checks, do tests pass? Do they assess correctly? Can you glean what the test is doing from the test name? Assuming the logic is correct, and the test has passed, it’s a case of looking for gaps in the process that are NOT being currently tested.

I like to use the convention of…

[UnitOfWork_StateUnderTest_ExpectedBehavior]

We also currently use gherkin syntax within the method to show the steps. Gherkinis a Business Readable, Domain Specific Language created especially for behavior descriptions. In a nutshell you specify the 3 main points of a test, including what you expect to happen using the following keywords GIVEN, WHEN / AND , THEN.

These can then be used as acceptance criteria and even be turned into Selenium automated tests with a little additional work.

Remove Unused/Commented Code

With the uptake in Git/TFS and other source code repositories it’s unnecessary to leave commented code when working in and around areas with them. I would actually state it’s your duty to remove it. If it was removed for a reason, the last thing we want is someone trying to reinstate it again!

Hard simple rule, if you see it, delete it!

DELETE! DELETE! DELETE!

And finally after all of the above we can focus all of our time and attention on the most important issue!

Tabs / Spaces and Bracket Placement

Like seriously, this should be the least of your concerns, but if you don’t have a company-wide linting/styling rules baked into your IDE then at least make the reviewer aware of company style guides and how you expect them to be adhered to. Over time less of these issues will crop up, but seriously get some styling rules created already!

Hope the checklist has helped, as always fill me in on bits I’ve missed, I’m sure there are some gems that I’ve left out.

And finally if you’ve found this useful please share this post using the buttons below, Tweeting is encouraged!

]]>http://blog.designpuddle.com/web-development/code-review-checklist/feed/01141Code Talk – Septemberhttp://blog.designpuddle.com/useful-blog-posts/code-talk-september/
http://blog.designpuddle.com/useful-blog-posts/code-talk-september/#respondFri, 21 Sep 2018 15:25:35 +0000http://blog.designpuddle.com/?p=1135Read More]]>It’s that time of the month again. Here are the most interesting posts I’ve found on the web this month.

Happy reading.

Planning doesn’t have to be the enemy of agile

Most tech companies will now follow an agile approach to their development cycle. Planning is an important cornerstone of management, and coordinating and controlling what will be happening next. However agile and planning don’t go hand in hand. See what is meant in this great article.

Having read about it a few years ago, it apparent use seems to have deteriorated. I feel it’s a very valuable tool in a developer’s arsenal, and something that should be used in code reviews and for the maintainability of your codebase. We all know to keep our code “Simple” We’ve all heard about the KISS principle, but were we ever told what simple really was, and how we should measure it?

Well this is where cyclomatic complexity enters the frame.

Definition

Courtesy of wikipedia:

Cyclomatic complexity is a software metric, used to indicate the complexity of a program. It is a quantitative measure of the number of linearly independent paths through a program’s source code. It was developed by Thomas J. McCabe, Sr. in 1976.

Cyclomatic complexity is computed using the control flow graph of the program: the nodes of the graph correspond to indivisible groups of commands of a program, and a directed edge connects two nodes if the second command might be executed immediately after the first command. Cyclomatic complexity may also be applied to individual functions, modules, methods or classes within a program.

What that actually means

In essence it’s the different number of routes through a piece of logic. To put it differently it’s generally considered in the context of a maintainability index. The more branches there are within a particular function, the more difficult it is to maintain a mental model of its operation. The metric is roughly equivalent to one plus the number of loops and if statements. This is a pretty good view of how the value is configured, yes x may be bigger than 100 and move straight on, and that path through would have a complexity of 1, however the code block/ method itself has a score of 11.

Why should I care?

Code coverage is becoming an integral part of the development cycle. Cyclomatic complexity ultimately effects the amount of different unit tests you will need to write for a given piece of code. Additional routes through a method will require an additional test to be written, and an additional place your code could fall over, or bugs could crop up.

When you take this all into consideration, the cyclomatic complexity of your code ultimately determines its effectiveness, simplicity, maintainability and general practicality. So yeah pretty important, don’t you think?

High “complexity” can be directly translated to low readability, and that also means it’s more difficult for new developers coming in and understanding what is going on.

I’m sure you have had an experience of looking at some code, where you had no idea what was going on, and why something was written “that” way.

So next time you write something, bear that in mind, that the next person looking at it might not be you. Leave it in such a state that you would be happy finding it in. This approach has always helped me when finishing up a new feature.

How important is Cyclomatic Complexity?

Who doesn’t love a good table, this one shows what the different values a method could have and what that means?

Complexity

What IT MEANS

1-10

Structured and well written code that is easily testable.

10-20

Fairly complex code that could be a challenge to test. Depending on what you are doing these sorts of values are still acceptable if they’re done for a good reason.

20-40

Very complex code that is hard to test. You should look at refactoring this, breaking it down into smaller methods, or using a design pattern.

>40

Crazy code, that is not at all testable and nearly impossible to maintain or extend. Something is really wrong here and needs to be scrutinised further.

These different levels help us better understand the code we are writing and the implication this will have on any testing resource we may need. It also makes us aware that any high levels of complexity will cause us problems in the future and time should be spent on refactoring this at the next available opportunity.

What can we do to fix this?

The table above shows the different levels of complexity and when you should start looking at refactoring your code. We’ll have a look at a few ways this can be achieved. By far the easiest way is to remove any un-needed if or else statements. These sometimes crop up during development and then don’t get removed. One common example you may find in your code base goes like this.

There doesn’t look a lot wrong with the code above. However, if we simply remove the else statement and move the default message to the declaration we remove 1 complexity point straight away. It’s an easy change and one that is common.

Another big culprit for high complexity are case or switch statements.

In certain cases, you can’t get away from blocks of code as above, that’s what they were designed for. But sometimes switch statements are just bad code design. The strategy pattern is a good approach to take if your switch statement is likely to increase. In the example above it is unlikely we are going to get new days added to our calendar, but take for example:

We have 3 case statements here, but one could expect that to expand, looking at what it’s currently implementing. Adding additional case statements is one possible solution for expanding this code, but that will increase the complexity with each additional case! A strategy pattern would tidy this up nicely.

It’s a higher setup cost, and slightly more complicated to begin with. However, after you’re 15 switch statement is added, you’ll be happy you decided to switch approaches! In addition, we have improved the complexity from the original 3 in the case statement to 1 in the Strategy pattern. Imaging if your switch statement was doing additional logic, and had additional if statements embedded, you can see this becoming a real struggle to test!

Use that noggin!

As with everything development related, the most important thing to keep in mind is that you don’t just change stuff because you want to.

Refactoring and improving your codebase is imperative to keeping a clean and concise environment. If you find your code is running smoothly, not causing you or your customers any issues, then don’t change it because a code metric is telling you it’s wrong.

Code is legacy the moment it is written, so your refactoring might be obsolete during the next round of development. Improve the code if it is being amended anyway. A good programmer should fix any issues they find whilst working on a story or feature, but not changing code that will require additional testing that doesn’t directly affect what they are currently doing.

Tools

So you understand the concept, you understand how to fix it, but what’s the easiest way to figure out what’s a potential problem! Well most IDE’s should offer some in built tools to help you out. I’ll run through a couple now:

I’ve linked to a great extension that I’ve been using recently, this will display the complexity at the top of the function!

There are tools out there for most IDE’s so go out there and find the one that suits you!

I hope this introduction into Cyclomatic Complexity gives you something to think about, and helps you sometime in the future. The additional reading below delves further into the subject so feel free to have a read if this topic interest you further. As always, let us know what you think in the comments below.

Additional Reading

McCabes full thesis: http://mccabe.com/pdf/mccabe-nist235r.pdf

A different perspective, why you shouldn’t use it? https://www.cqse.eu/en/blog/mccabe-cyclomatic-complexity/

And some more clarification: https://dzone.com/articles/what-exactly-is-mccabe-cyclomatic-complexity

]]>http://blog.designpuddle.com/web-development/coding-concepts-cyclomatic-complexity/feed/01112No Frills Keyboard Shortcuts (with Gifs) every Developer Should Followhttp://blog.designpuddle.com/web-development/no-frills-keyboard-shortcuts-with-gifs-every-developer-should-follow/
http://blog.designpuddle.com/web-development/no-frills-keyboard-shortcuts-with-gifs-every-developer-should-follow/#respondTue, 04 Sep 2018 09:53:25 +0000http://blog.designpuddle.com/?p=1086Read More]]>Shortcuts for me are the most productive thing that a developer can add to their repertoire that will aid them through their entire career. Learning how to use your system and tools will improve your productivity and in general make traversing all your windows and apps a breeze. The mouse is a great, tool, but if you can do it quicker, more effectively without your hands leaving your keyboard then you should! Here’s a list of my most used shortcuts, you’ll probably know or use quite a few of these already, hopefully there is one here you don’t!

Let’s get moving to Shortcuts people!

Generic Windows Shortcuts

These are generic shortcuts specific to Windows, these are the things you will use day in, day out, so get accustomed to these, and use them when you can.

First up is this post on how Netflix are personalising the graphics they show individuals when searching through the catalogue. It’s a great analysis of how A/B Testing works in the wild and even more impressive when you see the details they go into.

Next up is this though provoking article about test automation. As a relatively new concept it seems that most automation testers I’ve encountered are current testers looking to up-skill or grads looking for a way into development. The crazy thing is, having dabbled in automation before is, it’s extremely difficult to get right, and in essence is another form of programming altogether. This article really gets you thinking about our approach to this subject, and how in essence we’re doing it incorrectly.

Following on, is this lovely post on Travel. Travel has been propelled to dithering heights as a way to complete yourself and gain enlightenment. OK maybe that’s a little hyperbolic , but ultimately we look at it as a way to make us happy and improve our mood. This post explains why that is not always the case.

Algorithms are great, so If you create one, why not name it after yourself! Well that’s exactly what Tim Peters did back in 2002 with Timsort. If you don’t know this story, or why it’s the defacto sorting algorithm for Python then have a read of this great overview.

As someone coming into the industry it’s important to understand the bigger picture, seeing how all the cogs fit together, and how infrastructure, developers and more recently devops need to work together cohesively to keep your application alive! Obviously others may do it slightly differently, but this is the common approach I’ve see out in the wild.

My favourite conference to view the videos from is Goto. Here we have another great talk on breaking things! Who doesn’t love breaking things! I think we all look at our production environment as something sacred, that shouldn’t be touched with too much in case it breaks. Well this approach flips that on it’s head. Break it, break it all!