HTML is old, reliable and does not cost your users half a minute to download. Making it essentially that thing you write when the client doesn’t pay you enough to actually use React. And while it’s not very fun or exciting, it is in fact a thing that you can do for money. So as the world’s best HTML Programmer it is my duty, no, my MISSION; to teach you How to HTML.
Note: This is a parody, please do not try to actually learn how to html from it. If you’re looking for a real tutorial. Codecademy’s one is pretty nice. Also the one on FreeCodeCamp.
Now there are only three things you’ll need when it comes to HTML:
- Knowing how to use a computer.
- Having the stuff you’re going to be copying and pasting.
- And familiarizing yourself with the tags you’re going to be (ab)using.
Now, I trust you can take care of the first thing, so let’s get started with the second one:
No fancy intro this time. It’s the end of the year and we all know what that means. Here’s some ideas on a coders new years resolutions for 2019: Join the #301DaysOfCode Movement or the #100DaysOfCode Movement I’m adding both of these at the start, since I realize committing to something for 301 days may seem a little daunting at first. There is, however, no reason to not start out with both of them at once, since they have pretty much the same rule set: Code a minimum of an hour every day for the next 100/301 days. Tweet your progress every day with the #100DaysOfCode and/or #301DaysOfCode hashtag and the day number. Here’s an example on how to do both from my friend Charlie on Twitter: https://twitter.com/carlosermota/status/1075229858022809600 The movements themselves represent one of the greatest opportunities ever afforded to junior and upcoming developers. This is because you get to…
I made these some tweets as well in my account @orliph. But I also decided to leave the whole thing posted here in case someone was interested. This is not meant to be offensive. I’m just poking a little bit of fun at the things our Scrum team can make us go through sometimes. So without further ado, here’s the Twelve Days of Coding Christmas: The Twelve Days Of Coding Christmas On day One of Coding Christmas my Scrum Team sent to me: A Whole Day Spent Debugging On day Two of Coding Christmas my Scrum Team sent to me: 2 Linting Errors and a Whole Day Spent Debugging On day Three of Coding Christmas my Scrum Team sent to me: 3 Change Requests 2 Linting Errors and a Whole Day Spent Debugging On day Four of Coding Christmas my Scrum team sent to me: 4 Freshers Learning 3 Change Requests…
MobX has slowly built itself up as Redux’s main competition for state management real-estate. Which is definitely not a coincidence. Because, not only is MobX incredibly easy to use; it’s also very powerful. And, believe me when I say this: I’ve never seen React perform any better than when I mix the two of them. But, instead of me telling you, why don’t I show you instead?
A little bit of History: I’ve been working with Redux since version 1.0.0 came out. I was one of the early adopters at my previous company, gave courses on it, and tried to evangelize everyone to my cause. Pretty standard stuff.
Which means that, by the time I found out about MobX, I was already pretty familiar with the competition. Making me change sides was going to be no easy task.
And that’s when I ran into this video by Matt Ruby:
But, since it’s 42 minutes long, I’ll summarize it for you: Mixing MobX and React is like giving your car a consistent Nitro Boost while also reducing its fuel consumption by 90%.
What do I mean by this? The combination literally reduces the number of updates and (by extension) rendering to the bare minimum. Which brings your application to the peak of its performance.
If that doesn’t convince you to give this combo meal a try, nothing will. But, if being super fast is something that interests you, then boy do I have a treat for you next.
Should developers know design? Or should designers know development? This is an argument that’s been around for several years, although it was mostly aimed at the design crowd. But that could all change with the recent advancements in front end development. Developers could benefit now, more than ever, from understanding design and its principles. Ever since the good ol’ days of yore there have been tales of a magical being. This powerful hero was said to wield the powers of both a developer and a designer. With this might, she was able to walk amongst members of either guild as one of their own. And, should she deem them worthy, legends told she even had the power to unite them under her flag. I am speaking, of course, of the unicorn designer/developer. This particular role is still very much sought after. You will often find job listings including both “X years of design…
To do that I have prepared a list of my 5 favorite features about it. But, don’t get me wrong. I don’t mean these are the best ES6 features; that’s definitely up there for debate.
What do I mean then? Just that these are the 5 features that keep me installing Babel on all my projects. And I’m not even kidding. They just make my life that much more awesome.
So without further ado (and in no particular order) here are the 5 reasons why ES6 ROCKS, yo:
What is Test Driven Development? How does TDD benefit us and our team? And, How can we write effective and efficient Unit Tests for our code?
There’s a lot of talk about what organizations get out of pair programming. But, what about developers? How does it help us grow as professionals?
There are still a lot of questions around React Fiber. This article seeks to answer one of them: What does Fiber mean for rendering in React?
How does designing clean and beautiful code that makes people want to read and work on it? And, how does this code even look like?