To Be Continuous by Heavybit

This is a gem of a podcast. Hosted by Paul and Edith it has the right mix of technical and non-technical content. Paul is the co-founder of Circle CI and Edith is the co-founder of LaunchDarkly. Together they make a great pair. They put forward their ideas about continuous delivery and software engineering topics. Sometimes they even bring in guests which is like a cherry on the cake. The last episode #28 on Goal setting was amazing.

Tech People by Gistia Labs

In-depth interviews is what tech people by Gistia Labs podcast excels on. They bring in leaders from the tech industry to discuss topics from Angular in the enterprise to UX for Lean startup. The interviews are a bit long, still they are insightful and relay important information.

Mixergy by Andrew

Another admirable podcast is Mixergy hosted by Andrew Warner. With over a 1000 interviews with proven entrepreneurs, he knows how to ask the right questions. Andrew sometimes elicits such insightful information out of his guest. It is intriguing how he does it. If you ever want to learn how to interview people this is one podcast you can’t afford do miss. He generally interviews tech entrepreneurs. The interviews usually last like an hour. You even as a software engineer get to know important things about how to run a business.

I hope you had a great start to the new year and continue your learning listening to amazing podcasts. Cheers!

In the infographics below I will do a basic comparison between shared host, dedicated host and cloud provider. They are roughly comparable to an apartment, house or a mansion. I am over simplifying things grouping Virtual Private Server (VPS) and dedicated hosting together.

I hope this helps you to make the right choice about your hosting provider.

Why do a feature switch/flag?

My first experience with feature flag was when we had to deploy PayPal as a payment method. We wanted to be sure that it works without issues on production. How we did it then was to have a feature flag with a condition that the user email ends in @namshi.com.

You can do feature switch for various reasons, some of them are:

1. A very important feature needs to go into production and you need to test it in production. It can’t be released to everyone unless everything is fine like a new payment method.
2. You want to deploy a big feature in steps and until the last step is done the feature is not complete.
3. You want your changes pushed to production and merged with the main branch. But the new changes are not public yet.
4. You don’t want to spend hours fighting merge conflicts. You are working on it for days and your code has not been merged to the main branch.
5. You want to schedule a feature in future, you could have a feature switch based on date or time.

How to do feature switch?

There are many ways to do a feature switch for this post as an example I will add a new payment method to a checkout. For this task, I will use a simple if condition. Other ways of doing feature switch can be with a cookie or even some settings in the database.

Checkout Scenario

The simple checkout already has 2 payment methods Cash and CreditCard. We will add PayPal to it. The current proof of concept implementation only shows the order total. For, Cash it shows 5 more than credit card as it adds Cash On Delivery (COD) fees.

The code is an addition to my previous post on unit testing with Laravel. If you have not read it, I highly recommend you to do it. This example has tests too.

Checkout Example with PayPal

Let us take the example of a simple feature switch with adding a new payment method Paypal. It should be accessible only if your email ends in @gmail.com. You should use yourcompany.com email but for an example, I will use gmail.com.

Example Code

There is a simple Checkout service that has a calculateTotal method. It calculates the total depending on the payment method and now email.

The feature flag/switch code is in line 21-23. It checks if the payment method is PayPal and email does not end with @gmail.com. The endsWith method in Laravel helpers came handy to do it. So PayPal is only available if your email ends in @gmail.com. You can check this pull request for full changes and related tests.

Turn it off

So let’s assume, that you tested PayPal intensively on your production environment. When you are satisfied you just remove the condition and fix the related tests and you are done. Deploy again do a final round of testing and you have PayPal on production, all your customers can use it after that.

Conclusion

Stop making big tasks/tickets that take weeks to complete. Apply feature switch and deploy small things. Test them on production without anyone noticing.

Always test critical things on production in a hidden way like a new payment method. Practice feature switch and get your code passed through your work flow to production.

Hope you will benefit from feature switch and suggest it to solve complex problems.

Paper submission is not a lot of work

Some years back, I thought that submitting a paper to a tech conference was a lot of work. General tech conferences just need you to submit a title and a 200-300 word abstract that’s it. The organizers/paper selection committee decides to select or reject the paper on that basis. So just jot down those great abstracts and start submitting the papers.

You will be happy to know that some conferences also cover travel and hotel costs for speakers. So, if you get selected you get a chance to visit a new city/country and speak about a topic you like too.

How Do I know which conferences have an open CFP

Now, as you are excited to submit your ideas in the form of papers let’s see where you can submit them.

Below are some of the websites that inform you about Call For Papers (CFP):

1. Papercall.io - You can also submit your papers from this web application. Generally, lists only tech conferences. You can get a weekly update about events listed in PaperCall.io subscribing to The Weekly CFP.
2. Lanyrd.com/calls - Lists call for speakers for a lot of events. Events/Conferences are both tech and non-tech.
3. CallingAllPapers.com - Lists all call for papers with days left marker sorted with a deadline. It has only tech conferences listed.
4. The CFP Report - Sends a weekly with all tech paper calls. You can even select the day of the week you want the email, I get it each Friday :)

First time speaker? Content is king

Generally, first-time speakers do not get a chance to speak at conferences. So I recommend you to starts speaking at local meetups. It will be great if you record your talk and publish it as a blog post. This will help you land your first conference speaking opportunity.

Great, so your paper is selected at a tech conference after you already spoke at some meetups. Now after you sort out the administrative procedure like visa if any, you need to focus on your slides. The rule is simple, content is king. No matter you do a soft talk or a super technical talk with lots of code, you need to deliver great content.

Having a agenda or list of things you are going to talk about is a must have. Slides with content in bullets and optimal text on each slide is always better. Images play a vital role if you want to have that punch slide or convey your message in a visual form. I use and recommend right free images that I get from Pixabay and Unsplash.

Suggestions to speakers, feedback about your talk

Any feedback about your talk is always helpful. Four general suggestions I have for speakers are:

1. Keep your slides free from any grammatical errors.
2. While speaking try to avoid any Ahh and umm.. etc fillers.
3. Keep track of your speaking speed, don’t speak too fast or too slow.
4. Speaking is spontaneous. Still, try to memorize your starting and ending quote/sentence. You could even record your start and end sentences, listen to it and improve on it.

The best feedback is what your audience tell you. I have got comments and suggestions on the content, the demo code as well as how I speak. It has helped me a lot. One important feedback I got was that on stage I turn myself into a rapper :) (spoke too fast). So, the next talk I gave I was conscious about my speaking pace.

Always try to get face to face feedback one on one with people in the audience. Whenever possible have your talk listed on Joind.in. Have a slide towards the end to rate your talk and ask for feedback. Joind.in also has a page to list call for papers

Conclusion

Open up, submit your idea in form of a paper to a tech conference. As long as your talk topic is in-line with the conference subjects just go for it. Don’t expect your paper to be selected in all the conferences. Tech conferences get a huge number of submissions. Unless you have some solid speaking experience in conferences, it will be difficult. Be in the conference organizer’s shoes too. Getting a first-time speaker who won’t be able to deliver a great talk to a paying audience is a big risk.

Best of luck, hope your paper gets selected at a great tech conference.

Talk Accepted - Woo hoo!

My talk got accepted in around mid-May for #LaraconEu 2016. It was amazing news that entailed other things to take care of. I had to sort out visa first. I want to thank Shawn for keeping like 3 months + time between paper selection and the conference. This is great for speakers like me who have to sort out the paperwork. It is also useful for speakers who get enough time to prepare for their talk.

It is something that all conference organizers should consider when organizing an “international” conference. Select speakers/talks like 3 months or more in advance.

Suggestions to conference organizers

Then after I confirmed my presence, I started taking care of the paperwork for the visa. I also had a chat with Shawn over Skype. He gave me some pointers to make the talk more suited to the Laravel Developers audience. It was super handy.

Along the same lines I have 3 more suggestions to conference organizers:

1. Have a conversation with speaker after talk selection. Advise them about content.
2. Don’t always strive for fresh content. The speaker might have presented it earlier. Think of how the speaker can mold it to suit your conference audience.
3. Be adventurous with speaker selection. I agree it’s a risk to select a speaker who needs a visa to be at the conference venue. Still, if you give enough time like ~3 months things generally work out :).
4. Give speakers with potential a chance, have that trust.

Conference Experience

Let’s fast forward to 22-Aug-2016 now, I arrived in Amsterdam. I am here in Amsterdam after 5 years, still seems like nothing much has changed here :). I can’t write anything about the workshops as I did not attend it. The organizers were well prepared. All speakers already had access to the speaker’s handbook. The telegram group was useful too.

Most speakers were staying at Park Vitoria Hotel. It is right infornt of Amsterdam Central. 15 mins train ride from the venue and I must tell you its a great hotel to be in.

Speaker’s dinner

The ice breaking speaker dinner was great. Speakers interacted and got along well with each other. I guess they also changed their selected talks to attend talking with other speakers. I want to thank the organizers of Laracon EU for the effort they put into speaker hospitality.

Conference Day 1

Day 1 on 23-Aug-2016 kicked off like half an hour late due to minor technical issues. Taylor Otwell rocked the stage as usual. One thing, I noticed is even a seasoned speaker like Taylor gets a bit nervous before going to stage. So for us rookie speakers it is absolutely normal to be nervous.

Then I attended the talk by Hannes Van De Vreken about IOC Containers. The talk was quite helpful. We took the train together to the venue. Still, I was preparing for my talk that was after lunch.

My turn was next after lunch. Ubuntu wasn’t helping much with the huge display that needed 50 Hz refresh rate. After some googling, it played out well without issues. My talk went pretty smooth and I even got a few questions a the end. I guess I managed my time well.

More pictures from my talk here.

The slides of my talk are below:

Slideshare link

I wrote a small script to pull in the latest tweet with #LaraconEu for the demo which is here.

After that I attended the following talks for the day:

1. How to avoid database migration hell - which was good
2. Varnish For PHP Developers - that was a bit of too much code still good
3. One Box Doesn’t fit all - by Frank which was a different way at looking at scalability, still, it was a great talk.

Conference Day 2

I was more relaxed on day 2, I had no talk to do. Then I focused on getting the best out of the day. Below are the talks I attended:

1. Please Understand Me by Matthias Noback - Great talk about the tussle between Mangers and Developers
2. Lucid Architecture By Abed Halawi - Good concepts and well presented
3. Building Realtime apps NodeJs way By Sriram - He had too many slides so I was lost mid-way :)
4. Making the most out of MYSQL By Gabi - A great talk, good content and well presented. The experience of the presenter was visible on stage.
5. The State of content management By Tihomir - Generally a good talk, as I told to him the contents could be condensed better.
6. Curing the common Loop By Adam Wathan - Amazing talk a good mix of slides and live coding. Collections seems like the lodash of PHP world.

For more description of the above talks it’s best to have a look at the Laracon EU 2016 schedule.

The after party on day 2 was superb too. With live band performing and tech conversations around the atmosphere was electric.

For more photos from the conference do checkout the #LaraconEu tag with photos.

Amazing Experience

Overall, it was an amazing experience. The venue was great. Organizers put a lot of effort to make sure the speakers felt comfortable. I want to thank them. The comments I have received over JoinedIn about my talk have been very helpful, I would really like more ratings and comments :).

I am waiting for the videos like everyone else, I have some talks I missed that I want to watch. I loved being a part of such a vibrant event backed by an amazing community. Cheers!

Slides

Participants

The students were from Bsc. CSIT and BIM of second and fourth semester. They were high on youth and not worried about their careers. As it was a short talk, I wanted the session to be interactive. I was trying to get more questions out of them. Some of them were shy to ask the questions so they came in later after the talk to have a chat with me.

Questions

Questions centered towards roles and problems faced by tech companies in Nepal. I answered the queries with the things I knew and what I had experienced when I was working in Nepal. Few of them were enthusiastic about opening up their own company. I wish them best of luck.

Conclusion

Students get serious about internship, job and career only towards their final semesters. I think they should start planning for their internship at the mid of their bachelor study. By the ¾ stage, they should know which career path should I take.

I hope the short talk and QnA session helped some of the participants to think about their career plans.

How did it all unfold

The first talk was given by Amrit GC on “Ansible for PHP Developers”, then I presented my talk on “Simplified Gitflow”. After those two regular talks we had a lightening talk presented by Manish Jung Thapa (MJT) on PHP Developers Nepal Community. Last part of the program was an open discussion on “Does automated deployment and DevOps add value to the organization?” which got a lot of questions from the audience. It was great to moderate the open discussion. Overall, it was an amazing meetup. I guess there were around 100 participants which makes it one of the biggest PHP Developers meetup in terms of audience size.

My Talk on Simplified Gitflow

This is not the first time I presented this talk :). I had already given this talk at YIPL in Mar 2015. This time I changed the slides and made it more general. I hope it was helpful to the audience.

Slides of Simplified Gitflow

Video of my talk on Simplified Gitflow

More vidoes of the full event in this playlist.

Hope to see more meetups

Hope there will be a Developers Nepal meetup which is language agnostic soon. Kudos.

(Background image shot by me)

Software Engineering Daily

Software engineering daily is a daily podcast hosted by Jeff Meyerson.
He has worked at Amazon and knows what he is talking about. T he interviews are in-depth, long and enjoyable. Jeff is sharp, there is never a dull moment in the one to one interviews he conducts. He covers a wide range of subjects from docker/kubernates to logging and git.

Scale your code

Christophe Limpalair hosts Scale your code podcast. A new episode usually arrives every 15 days. He also interviews known tech personalities. The podcast covers a wide array of topics from open source to performance. This podcast informs how the big players deal with scaling and performance problems.

Scale Your Code’s mission is to organize the world’s programming knowledge from top sources and make it universally accessible to improve software security, speed, and reliability.

Scurm Master Toolbox

Scrum master toolbox podcast is another daily podcast with a theme for each weekday. Vasco Duarte hosts this podcast. He conducts the interviews with ease and a purpose to get the best out of his guests. Regardless of you do scrum or not this will help you in your career. Software engineers are solution providers. Understanding team dynamics, product management and change management is important in our work life.

For this time it was all podcasts with one on one interviews. Hope you like them and it helps you expand your tech horizon.

I have seen teams fall into this trap of git conflicts when they start using git and some type of gitflow. Merging branches to the main branch becomes a pain when there are git conflicts. In this post I am going to reveal 3 simple rules to avoid git conflicts.

Assumption

You have some working knowledge of git. You follow a git branching model like gitflow or simplified gitflow.

Rule 1: Keep your changes small

This is the golden rule to avoid git conflicts in teams. Conflicts occurs when 2 team members make changes around the same line of code. Like John changes like 5-10 in readme.md. Jack changes like 7-15 in the same readme.md file on a different branch. Have a rule of thumb that each pull request can have at most 20 files changed with 200 line addition. If changes are less there is less chances of having things overlapped. As a side effect, it will make deploying and testing changes easy too.

Rule 2: Rebase with your main branch (generally master) when it changes

When your main branch changes, rebase the branch you are working on with it. Usually master is the main branch so it will be best if you rebase with master at least once a day. This saves you from bringing in lots of changes done by other team member late. Its the same concept as above, get small changes step by step many times than getting it all at once. At the end of the day always do the following, given you are on your working branch

1
2
3
4
5

git checkout master
git fetch
git pull --rebase origin master
git checkout -
git rebase master

You get the latest master. Then you go back to your previous branch and rebase your branch with latest master.

Rule 3: Review pull requests faster and merge them to main branch

As I have stated earlier “An open pull request (PR) is a liability in at least 2 ways. 1 it’s a feature/fix not shipped to customers. 2 it will invite code conflicts soon.” Have a rule, pull requests need action by 3 days of opening them. You can review code, if code is ok deploy and merge or review code, fix issues then deploy and merge. This will help the team ship things faster as well as not have pull requests open unattended for weeks.

Useful Tip

You followed the above rules, still landed in a git conflict situation? Use git cherry-pick. If you have more than one commit in your working branch first squash it to one commit. Then create a new branch out of master/your main branch and do git cherry-pick <sha-of-your-squashed-commit>.
Given you have only 1 commit on your working branch feature11 and you are on feature11 right now, do the following:

1
2
3

git checkout master; git fetch && git pull --rebase origin master
git checkout -b feature-11-new
git cherry-pick 249bd9b150fdb1e6fc9e58af9823f70cc52579a3

In the above example 249bd9b150fdb1e6fc9e58af9823f70cc52579a3 is used for demo only. You can know your SHA hash with git log -1 being on branch feature11

Conclusion

There is no silver bullet to avoid git conflicts all the time. You will face it now and then. If you run into git conflicts everyday the process and system needs to change. Be logical, if you have a PR with 50 files changed and 700 new lines you will face conflicts.

I hope you face less git conflicts or even completely avoid them.

1. What is chatOps?
2. Why do chatOps?
3. How we do chatOps at Namshi
4. How you can start chatOps in minutes

(Illustration by Anjan Shrestha - AnjHero.me)

This post has the slides and the video of the whole talk.

I liked the overall experience of being a conference speaker :). I think the audience also had something new to fiddle around with by the end of the talk.

The speaker lineup for day 1 was very good:

For all the other news and views check the #codemodubai hash tag on twitter and on facebook.

Talk Abstract

Are you still deploying with capistrano? It is high time to put the chat bots to work. Using chatops to deploy your software gives visibility to all team members. It also gives a consistent interface to deploy. Software Engineers do not need to install any extra software to deploy. Ops is happy because software engineers do not need SSH access to servers anymore. Namshi is a Rocket Internet e-commerce venture in Dubai. At Namshi, we deploy all our apps with chatbots built with hubot. In this session, I will uncover some real life use cases of chat bots at Namshi.

Some lessons learnt

Just a summary:

1. Don’t be the last speaker of the day, people are already tired and ready to head home :)
2. Have a useful links slide that you can show towards the end while answering questions.
3. Content is king. Image intensive or text intensive slides matter less than the real content you want to deliver.

Slides

Video

(Thanks Prakash for the photo and video)

I hope the talk about chatOps was interesting for you. Cheers!

How do you distinguish between slow and fast tests?

Generally, if your whole tests suite runs in seconds it is fast. If your whole test suite runs in minutes/hour it is slow. To make your tests small you need to make your application small. As faster tests running on your Continuous Integration (CI) service will give you faster feedback. May be it is time to go micro-services?

Lets discuss the more about fast and not fast (slow) automated software tests.

The fast tests

Fast tests are code that test one unit of code generally a method. Unit test is a type of fast test. They don’t depend on any external dependencies. External dependencies include file system, database, web server, network or any third party API or service. Unit tests even mock the other code elements they need like other classes and its methods. This makes the test focused on one unit and they run in milliseconds/seconds not minutes. A simple example is below:

You can view the full code here, yes it is a simple class with no code or external dependency.

Some integration tests can also be fast tests. These integration tests can test many classes. They should not dependent on any external dependencies mentioned above to obtain speed. So these tests will still run in seconds and not take minutes to finish.

The not fast tests (slow ones)

Any test that takes long to run are not fast tests (slow tests). Generally, these type of tests need to load the whole application to test it. These types of tests depend on external dependencies. External dependencies include file system, database, web server, network, third party API or service.

Acceptance tests that need to load a full web application on a browser is a type of slow tests. Even smoke tests if it needs to load the whole application and takes long time to execute fall in this category.

The above example is taken from Sylius project, to test checkout with offline payment method on the browser.

Conclusion

Testing is super important for a robust software application. Automated testing + CI is one of the four pillars of any solid software application. Happy testing hope your tests run in seconds not minutes.

There is no pill to convert yourself as a good #programmer, it takes lots of reading, learning and practice. So start now :) #code #software

— Geshan Manandhar (@geshan) March 10, 2016

I browsed through my twitter timeline and collected them in one place.

Here are the quotes with visuals :

There is no pill to convert yourself as a good programmer, it takes lots of reading, learning and practice. So start now.

An open pull request (PR) is a liability in at least 2 ways. 1 it’s a feature/fix not shipped to customers. 2 it will invite code conflicts soon.

Talking about automated testing and Continuous Integration(CI) is easy, balancing it with delivery and cost as a web shop manager is hard.

Having automated tests but no Continuous Integration(CI) is like having a sword but letting it rot.

You cannot follow everything by the book. It’s generally an ish implementation like Agileish, Kanbanish and RESTish.

If you are thinking of a software product idea, make a pain killer people can’t live without not an optional vitamin people can and will skip.

Software engineers have power to create great solutions but the best software to solve the least important problem is of no use.

Programmers/developers need to become software engineers. Think of solution then technology to implement it. Think of abstractions then code.

Software developers are solution providers first, engineers second. Solution should have business value than using the latest tech fad.

If you don’t sharpen your axe then it will take more time and effort to cut the tree. Same goes for software development.

Disclaimer

Not all of the above quotes are created by me, some of them are inspired/adapted from things I read online and podcasts I listen to. Thanks.

We are currently using Travis CI for running our tests and our own open source Roger app to build docker images. The main objectives of the talk were:

• Suggest using Wercker CI to combine running our tests and building our containers in a sequence. This will prevent us from deploying broken builds

• Inform about a free service that can run 2 concurrent workers to build and deploy containers. It supports closed source projects too.

Here are the slides:

We discussed how it’s still in beta, which might cause issues in the future. We also discussed on how Continuous Delivery and Continuous Deployment are different.

Hope you like it :), comments and suggestions are always welcome.

Weeklies are compact and organized list of links with articles, podcasts, videos etc. They are focused to a related to a topic, technology, language or framework delivered to you email inbox each week. This post curates a list of 3 weeklies for all software engineer/developers. The main 3 weeklies are language and framework agnostic. Towards the end there is mention of some language, framework and CMS specific weeklies.

(Background image shot by me.)

Weeklies

3 great weeklies you should subscribe to are:

Changelog Weekly

Changelog Weekly comes out every Saturday. It give you a well balanced rundown of all things open source. It covers major headlines, projects and repos, videos. It also includes pings posted on its ping repository. So you can try a ping too :) ChangeLog weekly is a great way to stay updated. It covers all new open source news and repositories.

StakeShare Weekly

StackShare Weekly is released every Friday/Saturday. It includes a post on how one company scaled or improved its stack. For example last week it covered how ProLeads moved from Heroku to Docker. Then it summarizes new and top 10 tools, products or services. Stack Share has a great listing of many services, products and tools categorized well. Their newsletter is super helpful to get up to date with the latest tools and services.

DevOps Weekly

DevOps Weekly is released every Sunday. It recaps the major news, events and tools from the devops fraternity. As software engineers/developers we are going more full stack. This implies that we should also be aware of the system side of things. DevOps Weekly includes condensed links from docker and containers to monitoring, performance and security.

Other Weeklies

Some of the other weeklies I am subscribed to are:

• PHP Weekly

• Docker Weekly

• Javascript Weekly

• NodeJs Weekly

• Drupal Newsletter

Conclusion

If you are working with Ruby, python, Android, IOS/Swift or even go lang. The only thing you need to do is Google <your language/framework/CMS here> weekly and subscribe to it. I think you will like the curated links you get each week.

Weeklies have helped me get updated on the technology/language/framework/CMS I use or know. I hope it helps you in the same way. Happy weekly subscribing.

Docker enables using same software stack in development, staging and production. You don’t need to worry about the version of PHP, MYSQL or any other dependency with Docker. This post will be about Laravel and MariaDB (MySQL) with Docker for local development. It will also feature use of docker-compose. We will use PHP 5.6 and MariaDB 10.1 with Laravel 5.1.

Prerequisites

• You are aware about docker and is basic usage. If you are new to docker check an introduction screen-cast) or read this Docker for PHP Developers post
• You know about docker volumes and linking containers with docker-compose.
• You are running Laravel 5.x on your local machine with some PHP and MySQL setup. The setup can be local LEMP stack or XAMPP or something similar.
• You have docker and docker compose installed on your machine
• You have stopped your Apache/Nginx service and MYSQL service. It will free port 80 and 3306. If you are using vagrant and homestead then you can run Laravel without starting it.

Software Versions used

I am running this example on Ubuntu 14.04.2 LTS.

• Docker : 1.7.1 (Installation Instructions)
• Docker compose : 1.3.1 (Installation Instructions)

Why use docker?

The reasons to use docker are simiar to vagrant. There are some more compelling reasons to use docker and docker compose, some of them are:

Quick setup of development environment

The developer/software engineer does not need to know which version of PHP or MySQL is in use. All s/he needs to do is docker-compose up and wait for the images to download (around 230 MB). After that add a entry to the /etc/hostsfile like echo 127.0.0.1 project-name.dev >> /etc/hosts. Then the project runs at http://project-name.dev on the browser.

No need to install software on local machine

With docker containers applications are self sufficient. There is no need to upgrade to the latest version of PHP or MySQL. The right version is already packaged inside the dockerfile and also in the container. There is no problem of one developer running PHP 5.5 and another one running PHP 5.6. All developers run the same container. You can install PHP to run composer and other scripts.

Same software stack in all environments

Same docker container can be deployed to staging or production environments. The same software stack with correct software versions is used across environments. For example the problem of one developer using MySQL 5.6 and staging running MySQL 5.5 ends.

A NGINX proxy can be used to make the virtual hosts dynamic. This post is about keeping things simple.

Steps to running Laravel 5.x with MariaDB (MySQL) with docker

For this example I will use docker images with Alpine Linux base images. Alpine image is just 5 MB which makes it the best candidate for docker base images. We will use PHP version 5.6 and MariaDB version 10.1. MariaDB is a drop in replacement of MySQL and for Alpine only MariaDb is available. The example git repo for this blog post is available on github.

Install Laravel 5.1 on local machine

Run the following command:

1

composer create-project laravel/laravel --prefer-dist laravel-mysql-docker

I installed it on ~/Projects/misc/laravel-mysql-docker

Add larael-docker.dev to /etc/hosts

While it is downloading Laravel add 127.0.0.1 larave-docker.dev to your /etc/hosts file. It can be done quickly with the command below:

1

sudo echo '120.0.0.1 laravel-docker.dev' >> /etc/hosts

Setup docker images with docker-compose

We will use dydx/alpine-nginx-php-mariadb and modify it to suit our needs. It is a docker replacement for homestead. Both docker images are based on Alpine Linux which makes it small. Create the following docker-compose.yml file on root of the project:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

front:
  image: dydx/alpine-nginx-phpfpm
  ports:
    - "80:80"
  volumes:
    - .:/var/www
    - docker/nginx/sites-enabled:/etc/nginx/sites-enabled
  links:
    - mysql:mysql

mysql:
  image: dydx/alpine-mariadb
  ports:
    - "3306:3306"
  volumes:
    - docker/db/data:/var/lib/mysql

• We are using dydx/alpine-nginx-phpfpm image named as front, it has PHP Nginx 1.8 and PHP-FPM.
• It uses supervisor to keep nginx and PHP-FPM running.
• We copy the all the files in current folder inside docker at /var/www to execute it.
• Other volumes are there to override the sites-enabled with virtual host and supervisor config to fix an error.
• The second definition is MySQL for which the data is saved in ./docker/db/data folder.
• The front container links the MySQL (MariaDB) container with the name mysql

Create needed folders

In project root create the following folders:

1
2
3
4

./docker
./docker/db
./docker/nginx
./docker/nginx/sites-enabled

All MYSQL/MariaDB data that would generally be stored in /var/lib/mysql will be linked as volume from ./docker/db. This is done as docker containers don’t have data persistence. This will keep the MySQL data persisted on the host machine which will be reused when the MySQL/MariaDB container is restarted. The folder structure should be like below:

Create default sites-enabled

Create a file named default on ./docker/nginx/sites-enabled like below:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

server {
  server_name laravel-docker.dev;
  root        /var/www/public;
  index       index.php;

  client_max_body_size 100M;
  fastcgi_read_timeout 1800;

  location / {
    try_files $uri $uri/ /index.php$query_string;
  }

  location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
    expires       max;
    log_not_found off;
    access_log    off;
  }

  location ~ \.php$ {
    try_files     $uri =404;
    include       fastcgi_params;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass  127.0.0.1:9000;
  }
}

Run Docker compose up

Now give you are in the project root, you can run docker-compose up to build and run the containers. Wait for the containers to download. You can do more customization if you create your own image and do a docker-compose build to build the images.

After you run docker-compose up you will see output like below:

Fix permissions

The containers are up still as the cache and logs are not writable it will hit a 500 Internal server error. To fix this use the following command to relax the file permissions inside the container in a new console tab.

1

docker exec -it laravelmysqldocker_front_1 chmod 0777 /var/www/storage -R

or it can be done locally too with the following command:

1

chmod 0777 /var/www/storage -R

If you want to run your artisan commands you can run them inside the front container. Hit the command below:

1

docker exec -it laravelmysqldocker_front_1 /bin/sh

You will get the shell of the front container then do cd /var/www and php artisan all your artisan commands are there.

Access http://http://laravel-docker.dev

You should be able to load Laravel in the browser now navigating to http://laravel-docker.dev. Here you can see the Laravel 5 default page loading.

MySQL Settings

You can check if MySQL/MariaDB is running by logging into MySQL locally with:

1

mysql -uhomestead -psecret homestead

This will connect to you local port 3306 and you can see that mysql is working. You can even use tools like MySQL workbench to verify that MySQL is working fine.

From the container when you connect to MySQL the DB_HOST is not localhost anymore it should be mysql (as set in docker-compose.yml file) and you are all set to use MySQL. As an example have a look at the db part of .env file I used:

1
2
3
4

DB_HOST=mysql
DB_DATABASE=homestead
DB_USERNAME=homestead
DB_PASSWORD=secret

The easiest way to verify if Laravel is talking to MySQL/MariaDb correctly is just run the following command:

1
2
3
4
5
6
7

docker exec -it laravelmysqldocker_front_1 /bin/sh

## you will be inside the front container now

cd /var/www/

php artisan migrate

Then you will see some messages like below:

1
2
3

Migration table created successfully.
Migrated: 2014_10_12_000000_create_users_table
Migrated: 2014_10_12_100000_create_password_resets_table

Now run the following queries on MySQL/MariaDb via the cli client or some other client like MySQL Workbench.

1
2

use homestead;
describe users;

You will get an output like below:

Stop docker containers

You have seen that docker is running from the containers. To stop your containers you should run:

1

docker-compose stop

on the project root and it will stop the containers like below:

Next Steps

You can carry on using the docker containers to replace your local Apache/Ngnix and MySQL. You can develop your Laravel applicaiton with ease using docker and docker compose.

Conclusion

You can use this analogy that containers are cattle and virtual machines (VMs) are pets.

Creating, deleting and reconstructing the containers should be easy, fast and seamless than VMs. If you want to speed up your development flow and help other team members contribute faster to the project opt for docker and docker-comopse. Happy Dockerizing and coding Laravel + PHP!

(Background image Copyright Santosh Manandhar)

Full Stack Radio

Full Stack Radio is a podcast hosted by Adam Wathan. A guest joins in the podcast. The duo talk about software development related topics from product design to system administration. The podcast has a consistent quality and good selection of topics. One of my favorite is when Adam talks with Chris hunt about how Github does remote work.

Western Devs

Western Devs is another podcast that I like listening to. They have a panel of 5-7 participants and talking about tech topics. At times some of the participants seem to be quite still the discussion they have is informative. I liked the episode when they talked about Devops.

Startups for the rest of us

Startups for the rest of us is not a technical podcast. You should listen to it because software adapts to business and not the other way round. Many times its not about having that perfect code or applying that amazing pattern. It is about solving problems for people who were doing things in a manual way for example. If you have a business idea and want to start a startup this is a must listen. I liked the episode where they talked about things that done scale.

I hope you enjoy listening to these amazing podcasts. It will make your free time/commute more enjoyable and productive.

I have seen some software development teams are slow because they have a lot of technical debt. Some teams are naive, the members don’t want to explore new things . They are stuck with 5 year old technology like FTP, old legacy framework etc. In this post, I will shed some light on the four basic and important things of a solid software application. This contents of post is language and framework agnostic. It is applicable to any software project.

Assumptions

For this post I have made the following assumptions:

• The software development team is using some Version Control System (VCS) like git.
• There is some form of project management and team structure in place.

Maintainable Code

Making software work is super important, making it just work is a problem. I have seen teams writing code for the sake of making it work. Sometimes it feels like the code is there just for compilers/interpreters not humans. Code, simple, readable and maintainable is also important. We have discussed some rules about making code maintainable do read it. Naming things well and writing relevant code comments is also undermined.

Having a culture of code review always helps. If someone else can check your code before its merged to the main branch, it is a good practice to follow. It opens up more ways to learn how to code in a practical way. Code reviews are better done in systems like Github, Bitbucket and Gitlab.

Automated Testing with Continuous Integration

Having automated tests is important. Opt for the test type that matches your team’s current skill set. Unit testing are good to have. Writing testable code and giving team members the skill to do unit testing is an investment. Best way to approach unit testing will be grab the low hanging fruit. It will be better to start with Smoke Tests or basic functional tests. Doing a web application on each push/deployment? Check that all pages respond with a 200 HTTP response.

Step by step add more tests and time for your team members to gain more skills. As soon as you have some form of automated tests, wire it up with a Continuous Integration (CI) service. Some good options are Travis CI, Wercker, Shippable CI.

Automated Deployment

Finished feature should reach production from developer’s machine in less time. It will be possible using automated deployment using latest tools. Are you using File Transfer Protocol (FTP) in 2015? You should stop it now, the first step towards automation for a FTP user is use GitFTP. It is an automated way to get the changed files to server than copying it over a FTP client.

Do one step deployment and least human work. Tools like Capistrano, Fabric, Rocketeer are used for automated deployment process. To sum it up, the best deployment tool is… the one that fits your needs.

Logging with Monitoring

Logs are the only way your software application talks back to you. Gather all your system, application logs and make it accessible via a web interface. Follow the logging standard and use free SAAS to render your logs in a readable way that gives you value. If dog is a man’s best friend, log is a developer’s best friend. Understand and exploit the importance of logging in your software application.

Just having logs is not enough, view your logs after each change. Always check your logs after each deployment to track any suspicious activity. You can use Logentries or Loggly for cloud logging.

Conclusion

I have not focused on the server and devOps part of the software application and deployment. These are the practices all software engineers should adhere to. These should be the goals whenever a new project starts.

Without 4 stable legs even a chair falls. Save your application from going down follow these 4 practices.

Slides

You can also view the interactive slides.

Video

I talk about git flow for the first 15-16 minutes then I start answering questions on git and gitflow. Then I explain about other things in git which can be helpful. I did this presentation at YIPL on 11-Mar-2015. I know its a late post its like a part 2 of Do you git your code? Follow this simplified gitflow branching model to improve productivity.

Hope you learn something new about git and simplified gitflow from this video.

If you still use FTP at this time like 22% of Nepali developers you really need to move on. In this post I will briefly mention some deployment tools and try to analyze their pros and cons. Still as the title reads the best automated deployment tool is the one that best fits your needs.

What is automated Deployment?

Generally web application deployment needs some pre-defined steps to be done so that the software changes are shipped from the development environment to staging/production environment. It is done so that the changes are available for customers/users to use the new features developed by the engineering team. If some or most parts of your deployment process is manual it is not automated deployment. For example if you ssh into your server and do a git pull it can’t really be considered automated deployment process.

Automated deployment is a form of deployment where the defined steps for shipping code from a development environment to staging/production environment is one step procedure and fully or partially automated.

In my opinion, automated deployment is a language/framework agnostic need for every application as it saves lots of time and it can be one of the first steps towards devops culture. It is something both the development and system admin/devops team can work together to automate things. It will also open doors to further automation like continuous delivery, for example your tests pass on a CI service and the code can be deployed automatically to your staging servers.

Automated deployment characteristics

It should have the following characteristics :

• It can be trigged with just one action like one command on the command line and it will do the job.
• The steps will be pre-defined, reproducible and predictable.
• There is little or no human intervention from the start to the end.
• It should show the deployment progress as it happens, better feedback
• It should be atomic, which means either all the steps are completed or nothing happens.

Good to have features

Some good to have features for automated deployment tools are

• It should be able to deploy the same code in multiple servers
• Each deployment should be done from a given branch/tag/commit of a Version Control System (VCS) like git
• It should trigger notification in the form of email/chat message
• Everyone should be able to view which branch/tag is deployed
• When a deployment is in progress, it should stop other deployment to start
• Rollback of the last deployment should be easy and fast.

Free Tools available

Lets look at the free tools available and their popularity as per github activity in the table below:

• data is from 29-Aug-2015

So which one should I choose?

I cannot give you a clear cut winner from the above table, it will depend solely on your needs. Still as per your needs I can describe briefly the two tools I have used do. I have used Capistrano and Fabric. Let’s look at how they differ.

Capistrano

Capistrano written in ruby has been around as an automated deployment tools for years not, its quite stable and has support for lots of languages and frameworks from symfony to NodeJs etc. You can get more information about it from this podcast and the official docs.

The good thing about Capistrano is it already has a defined flow on how to deploy applications. If you can understand the flow visually and know how to make/edit a recipe and structure your tasks you are done. Another good thing about Capistrano as it keeps versions of releases and does a symlink switch when the view version is ready. Same thing for rollback, it is fast because basically it is just a symlink switch to the immediate old successful deployed version of the code.

Fabric

Python fabric is also an old player in the automated deployment domain, check its docs too. You can also get deployment scripts for some applications but the thing here is it is more like a remote command runner. You get a clean slate to structure your deployment process as you want then you can write your deployment commands and run then in the sequence you want. It give you the freedom to write the way you want and choose the sequence of tasks you want for your deployment procedure.

Other tools

Generally other tools are based on Capistrano style deployment, some say they are faster than Capistrano because they batch the ssh commands and run them once etc but the basic idea does not really change. I cannot peronally endorse any other tool as I have used them by my own.

What next

If you are already doing automated deployment you can look at making it even easier, like deploying from a Chat interface like Hipchat or Slack. It is termed as ChatOps where one can instruct a bot to deploy an application. If you don’t want to go the chat path, you can even build a web interface to trigger deployments like Samson by Zendesk.

If you have your tests running you can even explore continuous delivery.

Further more the whole deployment process can be revamped with introduction of containers and Docker. If docker is setup right, you may not even need deployment tools but it will surely take lots of resources to get the docker setup running and functioning correctly for production usage.

Conclusion

The decision to choose the right deployment tool that fits your language/framework, application and team needs will be yours. Try choosing a tool that will do the job well and can be used for a long time without big problems.

So the main catch here is, if you want to deploy a big application, want stability and structure go for the safer option like Capistrano. If you are just starting with automated deployment for a smaller application and want to automated deploy with your own custom flow use Fabric for its flexibility.

Choose the right tool and get started with automated deployment. Happy Automated Deploying. Bye Bye FTP and ssh into a server then git pull origin master.

Introduction

There are many startups listed on StartUps In Nepal as well, I hope these people have a good backend infrastructure and have given enough importance to making their technology strong and scalable. If anyone is trying to rewrite a product or thinking of redoing their product I would really suggest to go the API oriented path.

If you are thinking of the next big product or planning a startup/product, it is a good idea to not jump start a monolithic application. Surely if you have less time/budget or want to just build a prototype may be to pull up some investment it is advisable. If you are thinking of a long-term product to be used by lots of people start planning your APIs.

HTTP APIs first, language/framework second

Rather than just deciding about the language/framework for your application, rise above it and think about HTTP APIs that will be needed to complete your applcaiton or the Minimum Viable Product (MVP). How to make user of the HTTP verbs/methods GET, POST, PATCH, DELETE etc and make it easier for the clients to call your backend should be planned then you can decide on the platform (language/framework) that can be used to realize the plans.

SOA, Microservices or something else

You can go a Service Oriented Architecture(SOA) path or even look into Microservices. It is also advised to do RESTish/RESTful or somehow REST based API which accepts and gives out JSON. If you don’t want to make more desicions about the data structure and how to accept or give out data, try implementing your APIs following JSON API specification.

Strong backend and multiple clients

If you are able to plan all your data communcation getting and giving out data to clients in the form of resource URLs, then you can build a strong backend. When you have a strong and scaleable back-end it can handle multiple clients easily. If you have a performant backend then the same backend can serve a front-end Javascript framework or a mobile applicaiton as a client in a speedy and consistent way.

Why not build frontend parallel

If the HTTP backend is designed and documented well before creating it even a front-end first approach can be done. In this case, the frontend can be developed in parallel with the backend, if there is any change it can be adjusted accordingly.

If your budget and resources support you can have two teams backend and frontend going in parallel to build and realize your dream product. And remember a mobile application is just another frontend client to the scaleable backend your have already built.

Mobile first is a side effect

If you have a strong and well documented backend HTTP APIs it can be called easily from the your mobile applicaiton to post or receive any information. Becuase is data is stored centrally on a persistent store the backend HTTP APIs work like a communication layer between your mobile applications and the data store.

Speed and performance is another good side effect

With great brackends all your system needs to serve is JSON and accept only JSON over HTTP following the HTTP way of working. This means the backend does not need to spit out any HTML so there are no views to code or maintain. As the view and some of its logic is decoupled and placed on the the frontend apps the backend is fast and the performance can be fine tuned from the backend perspective.

Conclusion

Though it looks all shiny from outside, still it is a resource intensive task to develop HTTP API backend and have multiple frontends. Both can go in parallel but it needs well planning, documentation and even better execution. That is why it is generally not recommended for web agency kind small projects but having backend HTTP APIs is applicable to products which have long life.

Have fun building backend HTTP APIs for the next big thing product in your mind. If you build your product following API oriented architecture, mobile first, speed and performance are its great side effects.