DEV Community: Owen Far

How do we setup a proper development workflow?

Owen Far — Thu, 31 Jan 2019 14:09:35 +0000

When I built my first website, I remember I had only a few files and a couple of folders in my development project. These were mostly single-page websites, everything was neat and quickly accessible. Later on, I started building websites with their own content management system (CMS), containing hundreds of files, from markup to scripts, libraries and stylesheets, to different sorts of media files, back-end services, and more. How do we organize and properly maintain larger projects?

At first, I had no clue how to structure an architecture that can adapt fluently to changes and future updates. I didn’t yet understand how everything works, so I automatically thought that setting up a performant website was very complicated. In fact, the more I searched on the Internet, the more I was discouraged to move forward. I kept hearing about new frameworks and about new techniques, and tons of other methods that different web developers persisted that I should use as well. Instead of confirming what I thought is clean, simple, and right, I was confronted with many buzz words that I didn’t yet understand or heard of. From my research, by reading quality books and well-curated articles, I noticed that I didn’t know if what I choose would be the right decision, and I kept insisting with myself that I wasn’t ready yet — or so I thought. I was wrong.

The problem is that right or wrong doesn’t exist in web development, it is not defined in some Internet “mastery” book. The core architecture and the development structure of every website can differ completely from one another, but the basic construction of a website is very simple and straightforward. Different web browsers and web servers work in their own unique ways, and your challenge will always be to keep testing your products against new updates that might affect your website on these platforms. Browser vendors, network protocols, and web servers — as long as your website plays nicely around these three technologies, you can literally do whatever you want. At the same time, this doesn’t mean that certain standards and methodologies do not exist. As years passed by, web developers have come up with a few methods and techniques that paved their way as the industry standard. This is because they make technical sense, and following these defined and robust methods can help you build a proper structure and an architecture that you can easily maintain and adapt.

In this chapter, we’ll be looking at various ways web developers apply strategic methods to continue improving their web development workflow, and to easily keep their websites updatable and future maintainable. Setting up the right workflow is also very crucial to reach the best productive outcome, and whether we talk about the front-end presentation or the back-end services, everything starts from the local environment you set up on your personal computer. That’s what we’ll start talking about first.

Creating a robust local environment

When you design and develop your website, you should always try to apply the same behavior on your local development environment to match that of the live web server you will use. This will range, for example, from the type of web server you choose (e.g. the Apache HTTP version) to the back-end language version that you have installed on both your remote server and your local computer. By using this method, you can heavily reduce the chance that something will go wrong once you publish your website live. It’s usually also crucial that if the project is a long-term project, you keep notice that if some updates are done on the server, you apply the same updates on your local environment before you start any work. This lets you revisit the project several years later, apply certain updates or patches, and deploy to the live server resting assured that you don’t break the live production.

Some web developers recommend that you install a virtual machine (VM) for every individual project on your computer, so that it behaves the same as your live server. While this is a powerful and versatile solution, the downside is that it will drain the resources of your host machine — your computer. My own preferred way of dealing with this was to always have a staging (testing ground) version of the website on the live server.

This means that if a project I worked on was running live on the URL ‘example.com’, I created a sub-domain with ‘test.example.com’, and I deployed the updates on the staging area first to make sure that nothing breaks. This can be in any other directory, as long as it runs on the same server environment. Personally, this gave me the right confidence to deploy any changes or updates on the live server, as from my experience, your local environment will never behave the exact same way, even if you think so.

If you keep this in mind from the very start, you’ll be able to apply the right strategies, since the way you structure your website on your local environment will be the same way you’ll have to maintain the structure of your production version running on your server. The simpler the structure of your local environment is, the easier it will be to maintain both. For now, keep in mind that you will always have two environments of the same development, one living on your local computer, and the other on the web server.

This article is a section taken from Chapter 4 of the eBook ‘Mastering Web Development’. If you would like to read more, you can also download the free Sample Chapter from the website here.

Thank you for reading!

I would really love to hear your comments and thoughts — critics are always welcome around here too. Which are some of the best strategies you use to maintain a proper development workflow?

Until next time,
Owen Far

What annoys you the most about the Web?

Owen Far — Sat, 22 Dec 2018 10:03:19 +0000

I would love to hear your thoughts about things that annoy you the most around the Web platform.

Personally, these are some of the few things that keep getting on my nerves:

1) Frameworks

The fact that most jobs look for experience and "strong" skills in React or Angular. It annoys me that companies don't seem to understand that some developers simply use the vanilla approach.

2) Quality

There can be a big misconception between the quality of one website from the other. It annoys me that there is no easy way to know the quality, security, and user-privacy policies of the websites I'm using. For me, HTTPS just won't cut it.

3) Titles

It seems to me that everyone is becoming a CEO or a founder lately. There's no way of distinguishing the legitimacy of people and their work.

Please share with us, which are some of the main pain points you face when working on web development?

All the best,
Owen

Dream team != (is not equal to) success

Owen Far — Fri, 07 Dec 2018 18:24:21 +0000

I keep seeing companies bringing unnecessary complexities in web development for the simple reason of following the standard “corporate” hierarchy team-structure. I have recently experienced in person how a company can be brought up to keep such focus on the old fashioned standards, while leaving the coding environment to be poorly built. It made me wonder how much value they brought into building a dream team in a company, while completely ignoring the importance of advancing developments in areas such as the Internet and its ongoing technologies.

All the ambitions I ever had towards building “our” visionary product drifted away, as I was deciding to depart the company “ship” again. I saw what I’m inevitably always prone to see in many web companies. A company driven foremost by their financial successes, goals, deadlines, and building a cult of the complex. They implement so many strategies and unnecessary complexities that it takes them years or more to have the first stable version of their web-app running online. Throughout this time, they also get lost in minor details which make them blind from the real complexities that come after shipping and maintaining an online version of their product — be it successful. As long as there is a means for cash-flow, anyone has the opportunity to create anything they dream of. Unfortunately some of us aren’t as privileged as others.

Web development — if done by those who really understand it — should allow teams to build and update features simultaneously and effortlessly. Forget about how others are doing it. Discuss what we — as a team — can do to make things better. There will never be a single definition of a particular standard, as things will always keep changing.

We need to continuously find ways that fit the product’s best needs, and keep adapting to these changes. We have to start building less complicated cults and focus on what matters the most.

Look beyond the impossible and make a difference

Developers don’t always need a design to start implementing the basic architecture of a website. If we’re to be invited in more meetings about the stories and ideas behind the proposed future implementations, we (developers) can understand better how the development will evolve, and how it should change or adapt future changes. This is always helpful to us developers that care about maintaining a performant website online. It should never only be about the ship, ship, ship! It’s more about reliability, security, accessibility, and privacy.

Never get locked to one single web culture or “micro” ecosystem.
I just left a company were the primary focus was still based on back-end implementations first. After a year and a half, I couldn’t handle this front-end non-sense anymore. I was to be a lead front-end developer (and potentially a company “partner”), working with just two more front-end fellows, but more than twenty Java developers. Yes, you read that right. It was ridiculous to see the amount of wasted time it took for us to finish a feature. In its simplest explanation possible, here is how a feature workflow carried on:

Design
Markup & JS — My role
Copy, edit, paste markup into a back-end framework of choice
Help developers understand certain functionalities — My role
Compile and generate Web resources and files
Perform and run tests
Evaluate bugs — My role
Fix and re-touch markup — My role
Update design if necessary and hit repeat

I could never understand such a workflow. Perform and run tests aren’t tests after publishing a beta-version online. These are bugs that come out when the front-end structure is generated by the back-end framework. The steps from line three onward can be eliminated if you build a proper front-end architecture. The back-end should be mostly used to handle services through AJAX requests (depending what you build). It’s highly inadvisable that the front-end is maintained by the back-end.

I kept trying my best to move things forward to — at least — a leaner and more modern front-end workflow (no, don’t even mention React). Later on they brought a professional SCRUM master and the first thing he mentioned was that we have to get rid of this legacy environment (JSF anyone?). Their approach, while ignoring my advice towards no adaptations of complex frameworks, went towards the future implementation of AngularJS. Don’t get me wrong, I’m not comparing the above mentioned frameworks together. I would rather say to strive for no frameworks altogether. Check out last years’ statistics about the use of front-end frameworks.

After this, it’s been a month of a personal roller-coaster. For who knows how many times I did this by now, I decided to move on and stick more towards building my own visions and continue teaching online.

Let’s embrace the “vanilla” side of life

I studied computer engineering prior to enrolling to a more software based course, and this might be the reason why I quickly understood the JavaScript language during that time. I always chose to embrace the vanilla languages themselves, while taking a step backwards from the use of frameworks, platforms, and other form of huge libraries. I always believed that the complexity of learning these “code-stacks” rises by a factor of 10x or more. Since eight years ago, I knew that JavaScript at its core is the language I should strive to become the most familiar with, and I only keep proving myself right. A lot of these arguments come from the same ideas and research which will also be found in the book I’m currently finalizing.

Web development at the core is a pretty straightforward architecture — yes, standards. It is more the ecosystems and the complex cultures that had developed by time, which are making everything seem so complex and impossible to achieve. You have to understand that these frameworks and services are there to ease your development — and only that. It is not a requirement, nor is it possible to keep up with all the new Web packages released today. This is why I think we should embrace a little bit more the main web-languages that made the Web how it is today.

I would tell you right now to forget about the hundreds of available frameworks online and learn the standards instead. If you get stuck on something, use a friendly search engine to find your answers. Maybe find a smaller library that provides you only the functionality you require, instead of requesting a bigger library (e.g. jQuery), or a bigger framework (e.g. Bootstrap) simply to use a couple of functions.

Try to embrace the vanilla language first, and be careful what kind of packages you use and find online. Don’t always trust everyone straightaway. Try to be more cautious but also curious about building things with your own hands. If you want to invest time for growth, than dismiss or ignore the continuous use of frameworks and libraries. The Web is simpler than you might think, and by learning the standards you invest in yourself.

You should know that all the front-end libraries, platforms, and frameworks built today run behind the same technologies that make anything possible on the Internet. These technologies sum up our three front-end family languages: HTML, CSS, and JS. As simple as counting one, two, and three. Right? Jokes aside, things are becoming much simpler now more than ever. When you put the effort and try to understand how these languages work together, and everything behaves nicely on all the browsers, you will realize that it isn’t so hard after all — you only need to look for time and patience.

Closing thoughts

There are two main kinds of developers: You either come from the world of programming languages or not. Both of them may also lead towards different development pathways, but the easiest way to get started is to learn and understand the standards — do not create unnecessary complexities.

Sometimes we all prefer to choose the “fastest” or the “easiest” way of development, maybe because we lack time or money, but this doesn’t always result the way we expect it to be either. Sometimes it can get worse. I hear a lot of frustrations and other misfortunes arising simply because of the poor judgment and lack of proper organization behind the web development technologies chosen.

If you follow the standards and try to understand how everything works, you don’t have much to worry about. The term “from scratch” shouldn’t scare you either. If you’re patient enough, you will find anything you need online. Even if you don’t find the solution, you can always ask for help and get answers.

There’s a lot more we can discuss about the subject from today’s article. Let me know in the comments what you think, and if there’s anything you want me to discuss on coming articles.

Thank you for reading!

Until next time,
Owen Far

P.S. This article was originally published on Medium, but since I've discovered DEV.to, I'm looking forward to publish original content here depending on the feedback I get. I encourage you to leave yours below 🙂

How do I remove twitter from my DEV.to account?

Owen Far — Fri, 30 Nov 2018 19:15:08 +0000

I can't seem to find how to remove my twitter account. Anyone?