Returning to front-end web development

Leave a comment

For the past 4 months or more, I was introduced to my first front-end project in the company (after working partly on Visual Studio/C# and CI/CD-related tasks), and I was really glad to be able to work on something more relevant to my skillset and interest.

The new project required us to split an existing C# project (which had front-end and back-end code) into two parts — Javascript+React (SPA/single-page app) for the front-end, and C# (likely .NET, but I didn’t ask) for the back-end.

React-icon.svg

The good thing was, it was Javascript. Despite my inactiveness in web dev for the past 2 years, it didn’t take long for me to get back into it. The unfortunate thing was, I hadn’t been keeping up with the quickly-and-ever-changing web technologies.

In my previous job, I spent so much time with Bootstrap, jQuery and self-written native libraries, that I didn’t realise how much tech I had been missing out on. Thankfully, this project made me realise that I have so much more to learn, and I am glad I was given the opportunity to learn as I work.

Thankfully, I also had the opportunity to work with two experienced UI guys from the UK team, and I have a colleague sitting beside me who had started 2 months earlier on the project, to guide me through the project’s code, and explain its concepts.

I’m sure you can easily Google up articles about React, so I won’t elaborate too much about it. In a nutshell, I really enjoyed using React! And the concept of Redux was pretty hard to grasp at first, but once I got it, it felt really familiar, like I was writing game code (based on the idea of immutable states).

redux-icon

Regrettably, in my previous company, my ex-boss had stressed on the importance of testing, especially for web apps, but I never got around to learning or using them. Dear Andrea, if you’re reading this, I’m really sorry I skipped around the task and focused too much on writing the application code, instead of dedicating some time to write tests. I’m sure the tests would have helped shave a lot of time off discovering and fixing bugs.

jest-logo

But, now, I have had the opportunity to write in React, Redux, Jest and Enzyme. And I see the power of frequent, automated tests. I finally understood what unit, component and integration testing means. I now (sort of) understand why some people are so concerned about test coverage. I’ve learned so much in the past 2 months and I intend to pick up more relevant tech that complement the project, such as Webpack, ESLint, Selenium and more.

selenium-logo

Thinking back of my life journey up until now, I think it’s been quite a strange ride. I went from C++ to Visual Basic, to PHP, to Actionscript2/3, to Javascript, to C# (Unity), then to Haxe, to NodeJS, and now I’m back to Javascript (ES6/JSX).

I’ve come to realise that “programming skill” isn’t exactly about the prowess in the language, but rather, the ability to use as many complementing libraries as possible, effectively, to create the end-product. Heck, even non-project related tech knowledge would help a lot, e.g. Git commands, integrating CI/CD into the project, or using Powershell scripts to automate build and resource provisioning.

PowerShell_5.0_icon

On a side note, finally learning and writing tests for the React app made me realise that it must’ve been really difficult to write automated tests for games. Although Riot has written an article about how they tested their game (League of Legends), I imagine it must’ve taken some effort to get the initial tests working.

Hello 2017!

1 Comment

I’m a half-year late, but here’s a quick post to show that I’m still alive.

I haven’t done anything code-heavy for this year, unfortunately. I have been picking up some non-gamedev related programming stuff lately though, specifically React. The sad reality is that, developing web apps for businesses is less stressful and pays better (for those who genuinely enjoy web development) in Malaysia.

I think I’ve already said enough in my previous post from 2016, and my sentiments still sort of ring true today. But before I end this quick post, let me share this little video which I came across, that pretty much sums up my thought of “making it big in the gamedev scene”:

I really do hope to pursue gamedev again someday, perhaps as a serious hobby. But for now, I like the idea of having a decent stable job and spending my free time on self-improvement, like learning Japanese and exercising.

Goodbye 2016!

2 Comments

In case anyone is wondering if I’m still doing development, the short answer is yes!

The long answer is, not quite! But perhaps this last post for 2016 will shed some light on what’s been happening.

I had a long downtime. I guess I had an early mid-life crisis, because I was still figuring out my life, especially since my personal life is quite a mess. But I had a lot of time to think, thanks to that: Do I really want to make games, or do I just want to dream of making games?

My answer had always been yes, and I would justify it with grandiose goals and noble reasons. But the truth is, I was just chasing a dream. And like most dreams, mine went unfulfilled because I spent so much time fantasising over it, distracting myself in local indie gamedev social circles when instead I should’ve been seriously putting 110% into developing my game.

So 2016 has been a pretty huge year for me. I had hit rock bottom this year, but I won’t bore you with the details. On the bright side, I do think I have a clearer idea of where I want to go from here on.

I’m sure everyone had their fair share of good and bad moments this year. But let’s look forward to next year. Onward to 2017!

Server adventures 5

Leave a comment

Continuing my work in NodeJS & Paypal. Payout to customers is pretty straightforward — the documentation’s example was more than enough to get me started and I tested without issues.

paypal-logo

As for credit card payments, I hit a roadblock for a short while because I had to test with fake credit card numbers in the sandbox environment. I copy-pasted the sample code for credit card payment from the examples, but somehow the response JSON gave a “state:created” rather than the expected “state:approved” value. Without the “approved” state, my test merchant account wasn’t getting any money from the test credit card.

A quick google search turns up this link, and it seems like an outdated/deprecated list of test cards. Stack Overflow doesn’t say much either, but after reading through the documentation more thoroughly, I came across this text in this page (under “Test Credit Card payments” section):

  • Note: For sandbox calls, you can use the credit card numbers provided in your sandbox test accounts.

True enough, when you create sandbox accounts, you will find that these accounts will also have credit cards associated with them. Use those instead when testing, and it works — My test merchant account now gets money from the test credit card. Yay!