Coding and day to day developer related articles read by people passionate about learning and sharing.
Whether you are working Waterfall, or Agile we still need to quote out the time it will take for new features . We still need to give the product owners, or the people with the money, a sense of timing. And it is this skill or lack thereof that drives the experience we are going to have when we code.
Recently the Zaengle team was asked to look over an existing Laravel application and give a review of the overall state of the code. We were to act as an independent third party, between a new studio who had inherited the codebase, and the client, who was anticipating launching the product.
Startups need people able and willing of doing the actual work. They need programmers, designers, and eventually folks to do marketing, support, and more. What they don’t need, though, is someone who’s just going to be The Idea Guy.
This document will cover how to use a Behat specific API to setup a site for testing. What this includes is setting up a Scenario so that it has the data you need to run a test. This makes it possible not to rely on Seed data for this. This will allow us to run behat tests from remote machines as well as run tests in parallel.
We are working on using FeatureFlags or Toggles in our applications. For one we are aiming to do all our work on mainline branch at all times so this would be a key coding discipline to use FeatureFlags so we can hide a feature in progress knowing it will not interfere with the application. For example if a hotfix or another feature is ready to go to production we can push that with no worries of the in progress feature.
If you type git pull and expect a fast-forward update, but get a merge instead, don't panic! This usually happens when we're collaborating on a branch with other people, and we've made changes on our local version of a branch, and someone else (or the other you, if you use git to sync between multiple dev platforms) has made changes to the remote version of a branch in the meantime. It also happens really frequently in teams where all commits are to the master branch ... yet another reason to have a decent branching strategy.
Recent additions to the joind.in API have introduced some new dependencies so we decided we'd start using Composer to manage these - but we don't want to run composer unsupervised. I'm sure this will bring the rain of "just run composer install, it's probably mostly almost safe" criticism, but actually it's quite tricky to run Composer without excluding vendor/ from source control so I thought I'd share how we did it so that anyone who wants to do so can learn from my experience!
It didn't start out like that. When I first discovered TDD, it was like a courteous invitation to a better world of writing software. A mind hack to get you going with the practice of testing where no testing had happened before. It opened my eyes to the tranquility of a well-tested code base, and the bliss of confidence it grants those making changes to software.
BETA: This is a Code Heavy Read :)
Not all apps need to be an SPA (Single Page Application). Sure they have their place but in most cases the task might benefit from just a Blade template and Angular widget. This saves you from having to write an angular route which can be a tedious duplication of work. Also Blade is fast and fun to work with.