Recently I was asked for some advice helping a guest house to promote their business online. I gave a few suggestions of the top of my head, but I thought I would try and explain some of these ideas in more detail.
A friend of mine has recently introduced me to the Laravel php framework, and I have to say I am very impressed! I have been developing with php for a few years now, but it has mostly been building on top of what others have already built and I hadn’t really started my own project from scratch. This time, I thought I would use Laravel for my new project.
To some people, the differences in these two roles are obvious. A developer is the one that makes the code and the designer is the one that decides how it will look. But in my experience it is not as simple as it may appear.
There are probably about a million different articles and blog posts online that have a very similar title to this, but I thought I would share my own thoughts with you as each person learns something different. You will probably have your own thoughts on what is important when building an app.
I’ve always estimated development issues in hours or days but I recently created a new project in Jira and it only allowed me to use story points for estimates. I have always stayed away from story points as I have struggled to understand what they mean and why I should use them. But as the project only allowed me to use story points I thought I had better make a proper effort to learn what they mean.
Sometimes life as a developer gets you down. No matter how hard you work it seems like there is a never ending list of new bugs and change requests that keep coming in from your users. It’s easy to get fed up and start losing motivation, every day seems the same and time starts to drag. So how can you keep your motivation levels up?
When developing a Laravel web application it can often start out quite simple, but can grow in complexity over time. This complexity can also end up being reflected in your tests. Sometimes to run an end to end test you can end up spending longer creating the scenario for the test than the actual test. How can we keep tests simple and quick to write?