So, I visited China for the very first time – in essence, looking at my cultural roots. Along the way I have gained some impressions about China, as well as new views on old topics. This blog post summarizes my impressions of my first trip to China.
My travels to China also accidentally brought me to all of the four ancient great capitals of China – Beijing, Luoyang, Xi’an, and Nanjing. I had spent a lot more time in Beijing, hence the separate post. I didn’t spend as much time as I would have wanted to in the other ancient great capitals of China, but I had still taken some photos and notes.
It was a hot and sweaty night in the Nanjing airport. Cigarette smoke wafted across the waiting area in slow curls. Overhead, announcements were made that due to weather conditions, some flights were being cancelled. I waited, sweating, fervently hoping that my connecting flight to Beijing wouldn’t be cancelled. To much of my relief, it wasn’t cancelled, only delayed. I soon boarded my flight and arrived in Beijing, feeling very tired and worn out.
Exiting the airport, my travelling companions and I took a taxi to the hutong (胡同) where our boutique hotel was situated. To our dismay, the taxi driver simply dropped us off at the junction between the road and the hutong. His taxi couldn’t enter the small alley that is the hutong. At 1.30 a.m, we trudged into a dark alley, not even knowing where the hotel is – it was about 600m into the hutong. I was getting quite cranky at that point and my impression of China wasn’t very good at that point.
The next morning however, marked the beginning of a change of impression, of both Beijing and China on a whole. The booking of the boutique hotel was a good choice. In the light of day, I got to know the location, and it was impressive. The hotel is a siheyuan (四合院). The receptionist later intimated to me that it was built in the late Qing dynasty, making it about 140-170 years old. It was small (I would visit much larger siheyuans later), but surely impressive. It was quite interesting to think about how a family would live in a building with such architecture and how the architecture of such buildings dictate social convention and dynamics in a family. Continue reading
I went to a shopping mall today and I noticed they had installed a new feature in the parking lot – it’s one of those things that told you whether a lot was taken. If a lot was taken, a red light will shine, and a green light will shine if a lot isn’t occupied. I’ve seen a lot of those in parking lots, but this one actually interested me. Here’s how it looks like:
It’s a potato quality photo, but I think it shows how it works quite well. The system used is the ParkAssist M3. A camera is trained onto a parking lot. If there is a car with a licence plate in the lot, the system will know that the lot is taken, and display a red light. There are two cameras, so one light represents two spots.
As I walked past it, I had a hunch on how it worked – it uses computer vision, and one thought led to another, and I soon began to think about the two major ways of thinking about products. Well, technically there are three. If you were to give an assignment to any random guy off the street to design a parking lot monitoring system, there would be one of three broad response types: give up, innovation or invention. I’m not going to even deign discussing giving up.
This line of thought was quite influenced by a talk by Alan Kay I watched earlier this week:
After our shopping, I pointed out the cameras to my partner, who immediately asked “are those cameras?”, followed by “but that’s so wasteful!”. That was her inner electronics engineer speaking. Both she and I knew that there were cheaper, and probably more efficient methods of designing parking lot indicator solutions. She also highlighted her way of thinking: The innovator.
-  They had actually installed it at the end of last year, but I never bothered to notice how exactly it worked till now ↩
The week before last was a terrible week for me. It was one week after I had published my books. I was looking to take some time off from updating the books. After about 6 months being self-employed, doing the things I love to do, I felt it was time for me to return to the workforce. Let’s face it, it’s not easy to be self employed and get a steady paycheck. So I started looking for jobs.
All was well. I had applied to a number of jobs that I was interested in. By the end of the week however, I had nothing – nobody called back. Naturally, coming off the high of having just published a couple of books, it was crushing.
Remember a few months ago, I was mulling over acquiring a tablet? Out of sheer coincidence, I came into posession of a Nexus 10 a few days after I blogged that entry. It’s an older model, but hey, beggars can’t be choosers. Despite coming to possession of the tablet, I never really used it.
Anyway, back to the week before last. Combined with the fact that I got rejected for those jobs that I wanted plus a few more not so nice news, I was feeling pretty shitty about myself. So on Friday evening, I altered my state of mind chemically to relax a little.
After some drinks, I took out my tablet and fiddled with it while relaxing with pineapples. I decided to download my favourite game on tablets since 2011 – Jetpack Joyride. Now, when your brain is under the influence, time seems to slow down – your body appears to lag. Specifically my eyeballs felt like they were lagging. I kept looking at the right of the screen, and I could feel my eyes darting to look at the right and back to Barry on a very regular basis.
This led me to ask a question: what does Jetpack Joyride look like when one’s eyes are tracked? What would a heatmap look like? Clearly there are eye tracking devices out there like the EyeTribe or Tobii which is fantastic. But I didn’t have access to any of those. The front-facing camera of my tablet appeared to frown at me. Then it hit me: why not use it to do eye tracking?
So I dragged myself to the computer, and started learning how to write Android apps. To their credit, the Android developer page is absolutely easy to use – if an intoxicated person can read and create an app in about an hour, you know it’s bloody good documentation. I didn’t get far, except to capture videos and detect my face, which is easy stuff anyone can do. I went to bed.
Last year I wrote a blog post comparing programming languages to driving experiences. Today in the chatroom, my friends and I were talking about config management tools. I’ve had the opportunity to use most of them, so I compared them to operating systems as such:
|CM Tool||OS||Feels Like|
|Ansible||Mac OS||Here’s the one way to do things, chosen Your Lord and God, Steve Jobs. You can do things other ways too, but be prepared for a little pain|
|Salt||Linux||Do whatever the fuck you want to do. You have unlimited freedom. It might be a bit painful sometimes though.|
|Chef||DOS||Bash on steroids. OKay, so maybe it’s not like DOS, but you know, to fit into the OS analogy…|
Naturally, the above list is listed in my personal preference. I really really really like Salt – I’ve used it since its inception. But Salt is quite tedious to use – I have a repository of salt states for fuck’s sake. That’s not normal. Ansible is far easier, and for all the simple projects that I have, Ansible is more than enough. It’s easy enough that I can write playbooks from scratch without having to resort to a saved salt state. In a proper project setting, I’d probably be using Salt – less technical debt in the future – but for now Ansible suits my needs perfectly.
My experiences with Puppet and Chef are much much less compared to my experience with Salt and Ansible. But every time I get exposed to an environment with Puppet, I feel like the people who use it also probably write FizzBuzz the enterprise way. It feels bureaucractic to use. Ditto with Chef, except Chef feels more commandline-y, if you know what I mean.
With Salt and Ansible, I feel like I can go in and cowboy the entire thing (not necessarily a good thing), but not so much with Chef or Puppet.
Now, of course, I haven’t had much experiences with these – I’m not really a dev ops kinda guy – I just do what needs to be done. My experiences cannot speak for those people who are in dev ops for a career. So take what I wrote here with a pinch of Salt. ;P
After a long time spent in the editing room, I finally published both books that I kept talking about for the past few weeks in my blog. You can get them here:
Introduction to The Books
I recommend the latter book as a companion to Gayle Laakman’s Cracking the Coding Interview.
P/S: You can buy them as a bundle too:
I am glad to have published the books – I’m pretty tired at this point. I’ll probably do a write up on my experiences writing the books later. Until next time.
My brain is in overdrive mode again. I hate it. It makes me quite unproductive. I hate it when I’m unproductive. This post is a brain dump in bid to win my productivity back
I spent the early part of the day editing my books – pretty good effort with 1 chapter left to go for basic editing. Future edits can be done once the books have been published.
The rest of the day was spent with my brain in overdrive. No idea what caused it. Perhaps the increased sugar intake due to ingestion of carbohydrates. Either way I am overthinking the smallest of things.
The afternoon was spent evaluating a potential consulting gig. A yes/no thing took me more than 5 hours of deliberating. It was an astrophysics based statistics consulting, but I wanted more information. The domain specific knowledge usually helps me with decision making in any statistical analysis. I didn’t have enough trigonometry knowledge to take up the gig (well, I could do the statistics part, but not knowing the background of the problem makes me a poor problem solver). I should have rejected that outright. But I spent 5 hours deliberating on it.
I spent time brushing up on basic trigonometry, and then the ideas started flooding in. Maybe I could do this! Maybe I could do that! I could not calm my brain down. Maybe because it’s a Friday. I said no to the consulting job.
Then I had dinner. The food was okay. We had desserts. I recalled why I don’t actually have a food review blog – I could not stop mentally criticizing everything I ate. I deconstructed everything in my mind, down to its basic ingredients, and would be mentally telling myself how to improve textures, tastes and flavours.
One particularly sticky idea that I had was creating a milk that tasted like chocolate. By that I mean, normal looking white milk, except it was a chocolate milk. I felt like I had to go home to try. I didn’t get the chance to.
Brain on overdrive, I started overthinking everything. I went to the supermarket to pick up grapes and fruit. I thought about a joke about Abelian grapes and started chuckling to myself. Partner thought I went a little nuts, so I told her. She didn’t find it funny. Told the joke to 3 other people. Nobody found it funny. Told a number of other jokes that nobody found funny.
I started wondering about the concept and nature of humour and what makes people laugh. Clearly not me. Then I recalled the stereotype people laugh at. The Big Bang Theory was one of them. I used to like it a lot. Then I realized that you were supposed to laugh at the characters, not with the characters. Now I just watch it because I had followed it for 7 seasons so far – the sunk cost fallacy clearly affects even my currently hyperrational state of mind.
I cannot shut off. I am so tired. I know a few things will shut me off – movies, or drugs. Even with movies I don’t seem to enjoy them as much as I used to. I overanalyze every frame. I overanalyze story structure and see twists coming a mile away. I overanalyze cinematography and colour grading to get a sense of things. In the past this used to be subconsciously done. Now it’s active and conscious. It’s tiring.
So very tiring. Before writing this post, I sat in bed wondering how Superman would navigate given that he has just learned how to fly. Clearly navigating the skies by ground based landmark is one way, but then the vivid scene of Superman flying across the African savannah breaking up herds of zebras kept playing in my mind. It was a wonderful scene but it raises questions about how Superman navigates while flying. Birds can sense magnetic fields in their beaks. Can Supes do the same? Perhaps he goes home by doing the Christopher Reeve thing – flying to low earth orbit and re-entry. But how would he deal with the relativistic effect? Assuming he has a superior sense, he would definitely sense the difference.
By then it was obvious I needed a brain dump. My laptop is closest, so my blog is my tool. These things are running in my head all the time. I can’t sleep nor can I be productive. My thoughts branch out way too quickly and way too often now. I don’t really feel like sedating myself, and I don’t do trees alone, nor do I want to given my hyperactive state right now.
I’m just so tired.
TL;DR: I split tested the titles of my book: Here’s what happened
Oh wow, I’ve just had my first “satori” experience of rubber ducky debugging in a very very long time.
I first tweeted that I ran into a bug in Go, where upon running my code (with
Oh wow, ran into my first indeterminate bug in Go. Same code compiled twice produces two different results. Amazing
— Chewxy (@chewxy) February 26, 2014
I had a problem where when I ran the same code multiple times, there would be occasions where the program panics. It panics about 40% of the time. And I thought it was a problem with the compilation process.
This then led to a series of conversations between me and the always-helpful Dave Cheney. He led me down a different path of debugging – instead of using
go run, I compiled and ran the executable multiple times. The panic happens about 40% of the time again. This ruled out compiler problems.
It ended with him suggesting I email him:
@chewxy can you email me more than a tweets worth if background on the problem ?
— Dave Cheney (@davecheney) February 26, 2014
I had rather wanted to get on with my work and not spend a lot of time debugging this. So I sat down and wrote an email and described the problem. The more I described the problem, the more I got the feeling that I may have had everything I thought to be wrong. Until I wrote this line:
…a JSFunctionObject is created, and the pointer is placed in the FnHead node in the AST as the AllocatedValue.
Parts of the SSAForm generator actually accesses the AllocatedValue in the AST while the pointer of the JSFunctionObject is concurrently being set in the AST…
And then it became clear to me what the problem was. VERY VERY clear. I hadn’t even copied and pasted the snippets of code. My design of the program was wrong. And I know how to fix it.
I’m just wow-ing at the fact that the last time I had such a profound satori experience from rubber ducky debugging was years ago, when I was fixing up a machine learning deployment, and I had to explain the bug to someone who had completely no idea about anything programming related. I had to use very simple words and suddenly, it made sense. The same feeling was felt today, albeit with more Go-specific jargon.
I guess sometimes putting your code into english words makes a whole lot of difference.