It is now 2018 and I’ve just gone back to wordpress for ease of use and have been immobile for about a month with a broken ankle. I might eventually go back to ghost as I was liking it more and more, but their update process was far too involved (pre 1.0 to 1.0) and I was too lazy for all that. Hobbling around on this broken ankle has gotten super annoying as well so I’m glad that it’s almost been 6 weeks since my ankle surgery and I should be able to start partial weight bearing on the ankle this week. Thankfully my wife is a godsend and has made life for me bearable in this state. I hope to be my old self soon in about another month and a half.
As the title suggests, I have tried ghost out for a while, but it requires more maintenance than I’d like. Let’s be honest. I am lazy. I want a solution that involves either button clicks or maybe a simple
git pull, but ghost doesn’t offer that. Ghost requires you to download a new update, remove folders, replace files, etc. This is all trivial stuff, but I don’t want to do this. That said, I’m looking for a replacement with minimal maintenance and a decent user community. Somehow I feel like this is taking me back to wordpress… lol.
update: I may have been a bit hasty. I guess I’m not that lazy because upgrading wasn’t so bad. I’m still looking for any potentially cool blog platforms though.
Here we are in 2017 and iamchung.com has moved to the ghost blogging platform (self-hosted of course). I just recently overhauled the ec2 instance hosting all my sites and am now free of any type of hosting software to manage multiple sites. Instead, I’m using all the things I’ve learned along the way to just do it myself. It seems ridiculous to me now that I had to use the hosting software as a crutch for my weak linux-fu.
After using hexo for a while, my thoughts are that the concept is pretty great except I’m itching to start a new project. The next iteration of this blog will probably be a node/reactjs/redux project. While I usually try and write everything from scratch, I’m not going to reinvent the wheel too much this time. Writing a markdown to sql conversion script should prove to be an interesting task. Then again, who knows. I might just try and dig into hexo and see if I can make it do cool things.
As I was working on something earlier tonight and I ran
git pull to fetch updated code for a 3rd-party library, it truly dawned on me how amazing it is that we live in a world that is so interconnected where I can hit 8 buttons and fetch code that was written from almost anywhere. It’s not just code we’re pulling — this is someone’s hard work. After reflecting on that, I decided to take a drink and toast the person who had produced the code that I was using.
Right when StreetFighter V dropped earlier this year, I picked it up along with a Hori Mini 4. Now I’ve done a slight upgrade to a Qanba Q1, which is supposed to be a great beginner fightstick before you feel like throwing down the $200+ for a MadCatz TES+/TE2+.
One problem. StreetFighter V doesn’t recognize the Qanba Q1. At the time of this post, SFV on the PC only recognizes Xinput controllers (xbox360). All you have to do is get an Xinput wrapper application such as Xoutput which lets DirectInput controllers talk to Xinput APIs. Follow the instructions to install the Scp driver and then run Xoutput and configure the Qanba Q1 with these settings.
There is no button 12 so that’s what I put for the Back command since the controller doesn’t seem to have a back button. You can just leave it blank. I couldn’t figure out how to blank it out once I put the value in (which is really silly).
I’ve moved the site over to hexo and it is pretty sweet so far. At last generation, it created 213 files in 1.09s. Probably not nearly as fast as hugo, but it’s good enough for me. Still getting used to the whole deployment portion as well. Right now, I’m just manually deploying the rendered files via ftp, but I’d like for hexo to manage all that. We’ll see!
It is now 2016 and the age of static site generators is in full bloom. There is no end to the number of new engines/platforms emerging so I figured I’d take the plunge and try it out. I looked at a number of different options including hugo, ghost, and jekyll. I settled on hexo mainly because the community seemed fairly large and it was written in nodeJS, which has become my framework of choice for most new projects nowadays.
Why static generation? There are many reasons why you would want to stick with a dynamic website. Let’s say you want customized layouts for each user. You couldn’t really do that with static sites because it would defeat the whole purpose. Static site generation is about taking all that work that happens during a page hit, such as the application processing and database hits, and moving it to the moment you need to do any actual work to the site. Need to write a new post? After finishing the content, you would generate the new set of static files for the site and all the processing (and maybe database hits) take place then. When someone clicks a link to the new article you wrote, it serves up a static file which is lightning fast. Of course you could still achieve dynamic pages with scripting, but this is really about addressing the simple needs of most users.
I’m going to convert iamchung.com over to hexo for a whlie to give it a shot so we’ll see how it actually performs! I’ll write another post once the transition has been complete.
After nearly 7 and a half years at my last job, I’ve finally moved on and gotten a position at a new company as a senior software engineer. It took about 2-3 months of serious job searching and even though people will tell you that it’s easy to find a job in the tech sector nowadays, it wasn’t that easy (at least for me). I had a lot of applications out and went to a lot of interviews. I’m going to try and distill a little bit of what I learned.
The tech interview is a complicated animal. You have the initial non-technical phone screen where the HR person basically asks you all the typical questions like “What made you decide to look for a new job?” or “What did you like most/least about your current job?” or the classic “What made you decide to apply with us?”
After that, you go through a tech phone screen where a fellow techie will begin to grill you on some technical questions such as “What tech stacks have you worked with in the past? What did you like/hate about each one?” or the generic “Tell me about a problem you’ve encountered before and how you solved it.” Then they’ll start going into some real tech questions that may or may not involve an online collaboration website service so they can see how you code. This can include the typical interview-style questions similar to “Write a function that accepts a string as input and determines if the string is a palindrome” or, if you’re lucky, the standard Fizzbuzz. If it’s an algorithm question and the company is an actual tech company, they will probably supplement the problem with questions about the runtime (big O) and then might change the requirements ever so slightly to see how you adapt to change.
If you’re lucky and managed to pass all the phone screens, you get invited for an onsite interview. This is the hardest part, but even if you don’t end up getting the job, making it this far is still rather awesome for most companies in my opinion. Besides, if you make it this far, a lot of tech companies tune their interview processes to weed out false positives, which means they get false negatives. In other words, they might have rejected you the first time, but that doesn’t mean you shouldn’t try again later. They might miss really good engineers, but at least they’re not hiring people who can’t do the job. An onsite will typically last half a day or the whole day. The onsite is your best opportunity to interview the company as well. Don’t think it’s just them asking you questions. This is your time to make sure this is the place you want to work for. I had an onsite which I breezed through early on in the job search and that set off red flags for me because it seemed like they were just hiring anyone they could. You don’t want to work in that kind of environment because you can’t trust if your coworkers are competent or not. Throughout the day you will meet with a bunch of different people, most likely members of the teams which they are thinking of placing you into. This is to make sure you “fit” into the team culture and meet their needs. Some companies will make you go around to all the different people, while others keep you in a single room and bring everyone to you. This is usually not a cakewalk. During the onsite, you will be talking (mostly re-answering all the questions you’ve answered during previous phone screens) and whiteboarding. In my opinion, whiteboarding is the hardest part of the tech interview process. You are given limited time, limited whiteboard space, and a lot of problems. They want you to write bug-free syntactically correct code (no pseudocode) to see how well you do under pressure. I find that the better tech companies mostly ask generic programming questions, but if the position requires specific knowledge of certain platforms/languages then I’m sure they focus on those specifics.
After the onsite, you’ll probably talk to an HR person who will tell you that the company will get back to you as soon as they’ve decided whether or not you got the job. At this point, if you got the job, they will probably let you know very quickly. If you don’t hear back from them, that is most likely a flag that you did not get the job and they don’t want to put themselves in a position of liability by telling you that (which totally sucks). You’d think the bigger companies would be better about this, but even they do it. If you got the job, then congratulations are in order. If you didn’t, don’t feel too down. Try and remember where you might have had difficulties during the onsite and focus on training yourself to not make those mistakes again. If you can get the HR person to tell you exactly what you need to work on, that’d be great. Unfortunately I’ve found that most HR people want nothing to do with you if you didn’t make it past the onsite. As soon as you’re up for another interview round, they’ll be your best friend, but as soon as they get a negative interview result, they pretty much just clam up and try to speak to you as little as possible from what I’ve noticed. Anyway, hopefully these notes help someone out there.
“You’re standing on the surface of the Earth,” Musk begins, according to the book. “You walk one mile south, one mile west, and one mile north. You end up exactly where you started. Where are you?”
This is an interview question from Elon Musk to job candidates. There appear to be two answers. The first, the north pole, is the obvious one. The second is not so obvious. At any point on a ring somewhere close to the south pole, you could walk one mile south, then turn and walk one mile west only to end up right where you started walking west (circumference would have to be 1mi), turn and walk one mile north to end up right back where you started.