It’s honestly diffucult being a webdeveloper in the world of shitty websites. I guess that’s how hairdressers feel when they see my pathetic hair after it’s been a while since my last visit...
But the thing is, even though it’s technically easy to use scissors and clippers, I don’t do that on my own hair, I leave that to the professionals.
I had to learn Git as a programmer. If you want to easily collaborate on a codebase, you really need either Git or something similar. But as a non-programmer, you’ve probably never even heard that name, have you? Then why would you ever need it?
Well, for exactly the same reasons!
jQuery used to be virtually indispensable, if you wanted to develop a cross-browser website without getting a headache.
Today, however, you might not need jQuery, especially, if you’re developing a library and want to avoid unnecessary dependencies.
Still, some helpers could be useful... Vanillin is an opinionated set of helpers that I find most useful, a bare minimum to make life easier.
Keeping your classes immutable and stateless makes your code way less prone to bugs. Yet somehow this clean code rule isn’t as popular and as often invoked as SRP, YAGNI, DRY, KISS and others... Maybe it’s because of the lack of a catchy acronym?
Anyways, I’d like to take a look at two examples of when sticking to this rule could save your ass (or at least save you some time debugging).
Having 100% of LOC covered by unit tests certainly feels like a great achievement. But beware – that doesn’t necessarily mean your code is perfectly covered. Lines of code coverage is a really nice indicator of your app’s stability, but is can also hide some risks.
A musical competition, in which the managers lead their countries every week to a fight for a title of the best song.
Programming isn’t that hard. Really. With enough time and determination, almost everybody could write some useful code. The Internet is full of tutorials that teach you programming from scratch, full of people who faced the same problems you do, full of people who solved those problems and shared their solutions for you to use, and finally full of free libraries that you can just use. All you need to do is learn some tools, google your problems and put together pieces of code that you find.
But if it’s not a black magic, not a secret knowledge, then why are software developers so well paid?
Finally. I got to work and rewrote the code of my sweet blog. Brand new design, new framework, Micrus, better support for language versions, a couple of new features in the admin panel, ditching custom comments for the awesomeness of Disqus, ditching TinyMCE for the beauty and simplicity of Markdown. It was a lot of work, but it was definitely worth it!
Hope you like it! :)
Wreszcie. Wziąłem się do roboty i przepisałem od zera kod mojego blogaska. Zupełnie nowy design, nowy framework, Micrus, lepsze wsparcie dla wersji językowych, parę nowych ficzerów w panelu administracyjnym, rzucenie własnego systemu komentarzy na rzecz zajebistości Disqusa, rzucenie TinyMCE dla piękna i prostoty Markdownu. Zajęło to sporo pracy, ale zdecydowanie było warto!
Mam nadzieję, że się spodoba! :)
How big does a framework need to be to provide you with a quick, easy and comfortable way of creating neatly structured MVC websites? That can easily be extended and configured?
Well, not big at all. Just try Micrus! Its goal is to keep it as simple as possible, while offering all the most important features, as listed here:
Jak duży musi być framework, aby umożliwiał szybkie, łatwe i wygodne tworzenie ładnie uporządkowanych stron MVC? Aby był łatwo rozszerzalny i konfigurowalny?
No właśnie wcale nie tak duży. Wypróbuj Micrusa! Jego celem jest bycie tak małym, jak to tylko możliwe, lecz oferować wszytkie najważniejsze funkcjonalności: