scratchpaper by Joseph
In the last few months, I've been writing documentation for Ractive - a lesser-known but highly flexible UI framework. It's my go-to framework when doing personal projects or when I just want to make things work without futzing with tooling and all that jazz. But while the framework itself is pretty powerful, it has a weakness: It's documentation is a bit behind. So I've been fixing that and learned a few things along the way.
It's been a while since I last posted an article. I've been so busy the past few months that I have a lot of drafts but never had the time to just polish them up. Anyways, this time I'll be talking about unit testing, how code should be written to accommodate it, how testing should be done, and why prefer it over other forms of testing.
So it seems like the theme for this year's holiday dev discussion (more like holiday nerd wars) is the recurring idea of separation of concerns. The community is divided into two camps: The camp that believes in separation by language and the other is the camp that believes in separation of responsibility. So here's my opinion on a few things.
Whenever we work with content that comes from WYSIWYG editors, there's always feedback from QA about the styling not being quite right. Every time this is brought up, it's just dismissed as a WYSIWYG issue, that the nature of the content is just unpredictable during development. That's just a convenient excuse, and here's why.
I am behind on my writing. Got busy in the last few weeks being in a shuffle of projects. Different challenges, different environments, different tech stacks, my kind of fun. And if there is one thing I like about it this time, we now officially incorporate code reviews in our workflow.
HTML and CSS maintainability, scalability and reusability is often taken for granted. Just because HTML Just Works™ and we can just pop in a CSS framework that Just Works™ doesn't mean it doesn't require the same amount of attention as your JS architecture, your PHP code quality or your awesome Java code. In most cases, it's actually HTML and CSS spaghetti that will slow you down. Here's how you can cut down development time by keeping these 5 little steps in mind when building web interfaces.
A few weeks ago, I talked to the team about BEM, a simple naming convention that brings sense and structure to CSS. It was brought up because CSS doesn't get the same attention like the other tech used in the company. Its impact to delivery is often seen as negligible, dismissing it as just another bug in need of a fix. But unknown to everyone, it's dragging everyone back. As always, I get mixed reactions from the developers. Some find it fascinating, some find it silly, and others be like "meh". Here were some questions that were thrown in.
Being in different projects and roles is fun. I get to try every technology I can get my hands on. The goal is not just to get a finger on every pie, it's also to accumulate knowledge of what works, what doesn't and when, and apply improvements in other projects or projects to come. But if there is one thing that still eludes me, it's how to efficiently do Drupal development in a multi-developer team. More is merrier, but not without some challenges.
For the past few weeks I've been in, drowned and out of a pool of projects, mostly Drupal. You might think that "Ahh, Drupal. So you do the same thing every time like a production line?" - not exactly. Even though the projects build on top of the same system, they all have their... eccentricities. In particular, CSS is written differently for each of them. In this article, it's all about the two ways of writing CSS: context-specific and context-free.
This week was... crazy I believe is the right word for it. I was dropped into two projects, both of which are in the middle of their sprints. Taking out a day to set up for both, that left me with just a few days to work on them. But that's cool because we have project managers who can move worlds and make room for stuff. One thing they can't do, however, is deal with problems related to development workflow. It's something only we developers can do. Here's a few that keep biting back and may need to be dealt with when I get back to work.
My blog has quite a history. It started out on HelioHost as a plain WordPress installation, which eventually became a Wintersmith static site updated over FTP. Tired of the manual updating procedure, I moved to OpenShift to have it auto-build on push. Unable to work with CoffeeScript and Jade, I created my own static site generator written in vanilla JS. But writing in Node 0.10, the latest on OpenShift, was a pain. GitHub + Travis could have done the trick but reading about how to set it up was enough to drive me away. Then I remembered GitLab.
Came across this video on YouTube while reading Twitter. Very interesting, especially the part where the speaker kinda explains how microservices give more control to the developer, and reducing reliance to operations.
Every once in a while I'll learn something new, apply it to something real, and make a difference. I'm no dev-ops guy but I have always wanted to learn the tricks to streamline the development process, one that painless and from the eyes of a developer. Four months ago, I learned Docker out of curiosity. I was once a skeptic but it's just a matter of a change in the way of thinking that made me decide to move over. In this article, I'll show you what changed and how I use Docker.
Another two weekends passed since publishing my own static site generator Mechanical Pencil. It Works On My Local™ but during deploy, it just throws up.
EEXIST: file already exists, symlink ...
The error is very vague and there's a lot of unknowns in play that just makes it very tedious to debug. Spending another 4+ hours on it, I managed to get it to deploy.
Last month, I accidentally broke my blog setup. I wiped out the
node_modules directory for some experiment, and ended up not being able to re-download the dependencies due to some error. I thought I was done for, and was already looking for alternatives. Fortunately, all I needed to fix it was to bump up the generator's version. The older version relied on really old dependencies that didn't install well. However, I did build a static site generator... from scratch.
Recently, I've been writing my projects with Gobble. It's a pretty neat build tool. Feed it files, you get processed files, done. Pull in Rollup and Babel, then you've got an ES6-guzzling machine, ready to pull in your shiny JS. Drop in RactiveJS, a lesser-known but very powerful UI library, now we're talking business. Today, I'm going to show you some neat time-saving tricks.
So today, the package arrived. I got my Raspberry Pi 2 B! And even more amazing is it's so simple to set up! I got it as part of the CanaKit Raspberry Pi 2 Complete Starter Kit. It includes everything you need to even make your TV into an instant media center/super huge PC monitor. It even came with a bunch of manuals for me to entirely ignore (which I did). And so my adventure starts...
I took the week off... and a snow storm happened. Lucky? Maybe. However, my parents are more worried about me being idle rather than working. Apparently they see me as a workaholic... which I am... sort of... and that doing nothing will lead to withdrawal symptoms. I did what I can to keep my heart at peace by answering Vjeux's challenge and writing this article on rapid prototyping. After that, I dusted off my pet project and away I go, this time with ES6, Ractive, Gobble and Rollup.
In the past few months, I've been getting in touch with my inner self (a fancy way of saying "I just wanted to keep myself busy outside of work"). Originally, when I first encountered a PC, I wanted to be a gamer. But I was terrible at games, being headshot, zerg-rushed and all that (Yes, Couter-Strike and StarCraft: Broodwar). Then I wondered that if I knew how the game worked, I could be better. That led me to the world of software development, and here I am now. Now, I venture back into games...
So I have this little project, and I wish to use Ractive with ES6. Looking through my options, there were many... too many. Entry barriers in JS is getting higher and higher lately. I remember a few years ago, that I just needed jQuery and Bootstrap and boom! Instant awesome webapp. Now, it seems like you I to download a ton of packages, run a dozen commands, know a bunch of keystrokes, and only then would I actually start writing your app. That shouldn't be. So here's a zero-to-hero setup to get up and running with Ractive and ES6.
So documentation... I've been stressing this out since forever that an app should have an accompanying documentation of some form. People don't care. They just write code like there was no tomorrow. So this week, I transitioned to another project and found myself dumbfounded... ROFL ZOMG WTF! A pile of code with ZERO DOCUMENTATION. Yep! Zip, zilch, zero, nada, NOTHING! And oh boy I ain't seen nothing yet. Preparing myself for a whole lot of hurt.
For the last 2 weeks, I haven't been playing DOTA 2. I heard that Reborn client was promoted as the official client. Then I remembered that the Reborn client was nested inside the legacy client's installation folder. Without hesitation, I wiped DotA2 from my PC and had Steam redownload it. Now the install folder only contains the Reborn client files. Then I remembered... I forgot to backup my autoexec.cfg! The adventure starts!
Those who don't refactor bad code are doomed to repeat it.
- Me, Just now
Yesterday, I tried to create a single component comprising several input fields for a person's name. That way, anyone can just drop in this component anywhere and it should look the same everywhere. I spent all day writing it The Right Way™ and in the end, some hacked-up validation logic which didn't follow framework convention pretty much screwed it up. Now, I was forced to (gasp) copy-paste my logic everywhere instead of housing it to one component.
So... I just happen to take a long nap and ended up wide awake in the middle of midnight with nothing to do. So I decided to play DotA2 and behold, an update! The update states that the Reborn client now has autoexec.cfg support. However, no one has posted any update on which console variables are supported and which ones were dropped. So I went on an adventure to find out.
A sane application starts with sane data structures.
This was what our data structures professor told me when I presented my project a few years ago. I have followed this mantra ever since. A sane application starts with sensible data, and works it's way from there. The UI is merely decoration. However, time and again, project after project, debugging hell happens. And it all boils down to data structures, specifically about failing to determine what derived data is.
So here I am again, trying to market the idea of "components". Yes, because project after project, I hear these:
If you're one of the people who get this often and wonder what you can do with such, this might just be your lucky day.
So this weekend... Fallout: New Vegas. Yes, I haven't played this game yet. I already played Skyrim 3 times with 3 different character classes. Got bored between the second and third that I did Fallout 3. Game wasn't interesting, only the backstory, especially when you find out that the whole vault thing was an experiment. Now it's off to Fallout 3: New Vegas.
"Criteria of satisfaction: [vague specs + single-state wireframe]. It should work the same as [some other section in the site]. Here's a screenshot [single-state screenshot] of what it looks like."
So tell me, how does the other section work? Guess what, nobody! I know right? Sweeping criteria of satisfactions, very weak task descriptions, "should work the same as". Not really helpful in any way. If you're one of the people who get this often, strap up because you're in for a bumpy ride in a wild chase between business, management, development and everyone else who feels important.
"Just do it" Nike said. "Just do it" Shia LaBeouf said. Well, I did it. So they said that make your weekends productive by learning a few things. Two weeks ago, I ended up playing DotA2 and Planetside 2. Now, I got myself to budge and do stuff.
Hello there! It's been a long time since my last blog post (May?). Actually, there's been technical issues lately with my blog. It just got clunky to work with especially if you have to work with different machines, in different locations, and different moods. If you add a very terrible hosting service, plus a terrible blog framework... you flip tables!
Just when I though I had to clone back my blog and set it up again, it so happened that I have a backup on my PC. Yey! I can write a blog post! This time, it's a quick guide on setting up a FirefoxOS phone for hacking. For this post, I'll be on Windows and the victim is a Cherry Mobile Ace. So hang tight, this will be a quickie!
So it's weekend, and I think I need to take a break from writing code and research on the latest tech. I need something that causes my curiosity to run wild, but not something that's related to work. So I decided to play Skyrim... again. However, I had to reinstall because I uninstalled it recently. I have to go through it all that painstaking installation and customization again. So so why not make a post instead and not forget?
To people who immediately say I'm an idiot, then you're probably a good programmer, but a terrible mentor. True that React + Flux is efficient and makes sense, but for the people like us who have not been taught The Right Way™ of creating apps, it's somewhat a big leap. jQuery has helped people a lot, but it has created monsters out of developers. Architecture-less applications, stateful HTML and all those stuff. So here, I outline where I have been, what I did, and what I learned off of these adventures. Hopefully someone will stumble across this and be of help to them.
Ok, so... I graduated yesterday. Nothing out of the ordinary. I was expecting something like a "level-up" sound effect like in the games we play. Welp, I guess I play games too much. Since yesterday, all I have been doing is... nothing. Then a post from a classmate said: "What's next?" That got me thinking. Uhm... Hmm...
While I'm rolling in bed, fixing code some teammates's code in the dead of midnight, the thought of "avoiding local component state" keeps crossing my mind. It's due to the fact that I develop components which tend to keep local state rather than share its state directly with the cache layer of the app (model/stores/whatever). This I tend to avoid, but generic components do need to have some internal state somehow, especially when it's not concerned with the data at all. However...
So in the previous blog post, I talked about buying a new phone. That's because I broke my Android phone. I curse the idea of putting a phone in the back pocket. It doesn't just bend your iPhone 6, it also puts internal stress to your regular plastic smartphone. While I could buy a new one, it doesn't mean I should buy a new one, especially if... I still have my toy phone.
So this week I broke my phone. Typical problem with LCD-based screens (TN, IPS, and the likes) is that it's liquid between 2 panes of glass. Subject the phone to enough pressure, the glass will cease to work properly. In my case, the screen had some serious ghosting/burn-in.
And when your phone is a "local brand" that doesn't have a service center nearby, you're out of luck. The nearest would still be in another province and service would cost as much as buying a new phone which I plan to do starting off with window shopping.
So it's Christmas vacation, the new year to be exact. While others are partying and getting fat with food, I am... I don't know... 12 hours into trying to convert the module system we use at work from RequireJS to Browserify. And while I'm at it, I'll just throw in ES6 support as well...
Which I just succeeded 5 hours into the first day of the new year.
So today I brought my bluetooth mouse to work, because I was going portable with my laptop to chase the pocket wifi signal (the closer to it, the better). This also meant leaving my tangle of monitor, keyboard and mouse setup at my desk and moving closer to the less populated areas of the office... Welp, that was the concept.
The goal of applications are simple: Modify data, display data.
I dunno why applications are so hard to build for such simple purpose. We have a lot of tools here, libraries over there, hype everywhere. Then talk about "the right tool for the right job". I dunno about you people, we're just fiddling numbers and strings. Keep it simple!
One of the few hobbies I have, if not the only hobby, is building small JS libraries, experimenting with new APIs and trying out development strategies. And over the course of experimenting (which mostly happens at work :P), I have come up with ways to building stuff in a manner that is not only faster, but easy to wrap your head around. Zero-magic, pure swordsmanship and maybe a bit of thievery. Here's a few of them.
So I just came back from Drupal Camp Cebu 2014, which was... I'll explain later. Just thought I'd post about it while I'm still fixing that AC100 and SAO 2 episode 19 downloads. So how was the event? Hmm, I had mixed feelings about it for one. Let me get this straight before hell breaks loose: It didn't suck.
So today marks the first day of the sprint at work, or at least was kicked-off today by way of a sprint meeting of our team. The sprint actually started yesterday so whatever. Anyways, sprint is a word usually associated with moving fast, and in order to move fast in code, one must have a good architecture.
For 2 weeks now, I have been rewriting part of our website. The Flux architecture has proven to be so simple, gone are the headaches of 2-way binding which I formerly tried to promote. I used to pitch like "With 2-way binding, never will you touch the DOM again!" and "jQuery will be reduced to an AJAX library".