Button only embed – Waltz for one – Can only play once then must wait 30s to play again
Unlike a normal embed code, the tiny embed code in CLAS will have the “display:inline-block” style by default, so that you can put it in the middle of a line of text or other web element. To put it on a separate line, simply add a br tag.
“audio only” embed – CLAS native video (HTML5)
So I was politely accosted by a psychology student running an experiment while going for lunch. The task was to solve brainteasers (arg! my only weakness!) in 2 minutes. Each right answer increases your chance of winning a $200 draw. I immediately felt a sense of certain doom. I was stuck right on question 2! Right then, a lost looking student asked me the direction to a library, and so I stopped thinking for a few seconds to point him along. He confirmed the direction again, and asked if the library had a water fountain; and the whole conversation took about 20 seconds.
I got back to my task and, strangely, saw the answer to Q2 right away, just when the time is up. This was when I suspected that the student who asked me for direction was a partner in the experiment, and the point of the experiment was to see how people react differently in social situations when stressed for time. It turned out that my guess was spot on. The hypothesis is specifically whether you would be less willing to give time, when you feel a perceived lack of time, and a perceived value placed on your time.
The student didn’t count on the fact that I have chronic migraine and work in a “0.6 programmer, 0.4 everything else” position. Being starved for time is a main theme of life. But there was a surprise ending to this, and it surprised me too…
I was the only respondent in his study who managed to answer more than 1 questions so far. The brainteasers were deliberately difficult to induce the necessary stress. In fact, most respondent didn’t manage to answer even one of the brainteasers.
And I am terrible at brainteasers… I hate them with a fiery passion! What I think happened was that the act of giving time to help a stranger allowed me to overcome a mental block. Or perhaps it was because I felt a bit better after helping someone, getting a jolt of dopamine to block out the bad feeling of being stuck at “questions that may be linked to my IQ.”
The bottom line is, state of mind matters a great deal, and we certainly can control it to make our life and work better. Often, when you give time, you get more back.
Case in point, this little game a close friend and I made for a development challenge: produce a real-time-strategy (RTS) game in a week. Being eternally time-starved, I decided that I might as well learn GIT, Maven, and the IntelliJ IDE while I’m at it, instead of using something I’m used to like SVN and Eclipse. We also had nearly zero idea of how to make a real time strategy game. Recipe for disaster right?
- Day 1 to 3: fumbling with GIT, IntelliJ, and Maven. Argued with each other about what the game would even be about. We finally decided that it would have something to do with defending a wall, and that you will control just one character, a human veteran, who runs around shouting orders to a bunch of orcs who are so peaceful that they would not stop tiling the field even when an army of monsters bear down on them. Great concept! I think. But we had absolutely nothing to show for implementation, after half of the allowed time! Our moods were certainly not great then, but we decided to have some faith.
- Day 4 to 5: fumbling with the actual graphics / audio engine that we use to build the game (you think we actually know this deep stuff beforehand when I didn’t even know how to build a java project with Maven before we started?). At the end of day 5, we got the first demo to build: a guy standing on an empty grass field, in complete silence. He walks left, right, up, down, but there is nothing and no one… Unless we manually code in some scenery tiles like mountains that he cannot walk through.
- Mid of day 6: got some enemy sprites to randomly appear on screen, got a multi-layer map tiler data structure in place so that we can put a few trees and mountain sprites. The enemies still don’t move, but touching them and you will die after a few seconds, mysteriously, in complete silence and with a complete lack of visual feedbacks.
- End of day 6: got enemies to move, got allies to spawn, the map system now read up a text file for each layer, so I can make a bunch of text files with “t” for tree sprite, “w” for wall sprite, “m” for mountain sprite, etc. Got a single sound file to play for the first time.
- Start of day 7: within 2 hours I had the idea of making a new “map tile” layer and fill them with semi-transparent sprites, creating a limited range-of-vision effect. In 2 more hours, I put together a system for switching music tracks smoothly based on how many enemies are on the map, and how much damage the wall has taken, and adjust the mood of the music accordingly, from suspenseful to frantic to despair. During the same period, my friend put together a rudimentary game AI. Enemies now slowly come down the map in a threatening, mock-intelligent manner. This is all smoke and mirrors in the back, of course, but unless I tell you, you would swear blind that the monster army know how to flank and ambush.
- Mid of day 7: I franticly scoured the web for creative common graphics, sound effects, and music to put into the game, and my friend drew what I couldn’t find quickly enough. The thing now looks like an actual game! I added minor effects like when an attack action happens, it’s not just stats being subtracted in the back-end, but there is a sword slash animation, a claw slash, and a sound of metal hitting metal. My friend coded win / lose conditions, key targets to destroy and what to protect, and put together a very basic UI, a screen for the start menu, one for winning, and one for losing. All of those screens reuse the code from the very first demo, just a single background image, in this case, with text baked on them. I start to play test the game and tune the parameters of enemies so that the game is challenging but you won’t lose too quickly.
- End of day 7: I recorded and mastered voice acting for the game. My friend spent the time optimizing the code, because the game, by this point, throws out enemies and allies by the hundreds, whose movements and health must be tracked. I continued to play test the game endlessly to the very last seconds. We are utterly exhausted by this point, because, I forgot to mention from the beginning, we have been working on this game demo after going to our full time jobs. So when I said “start of day”, I meant 5pm; “mid-day” meant 9pm; and “end-of-day” meant 1am. We did this for fun and love, mind you.
But at the end, we had something that looks like an RTS, and may even be called “fun” (your mileage may vary, unless you grew up considering things like Battle Toads fun), from the beginning of having almost none of the skills to make such a game.
Looking at the timeline, you may notice that the amount of productivity seemed to grow like a bacteria colony: negligibly tiny, then excruciatingly slow, then somewhat fast, then really fast. I believe that all projects are like this. After enough ramp up time, and trust your dev team to tell you how long is not long enough yet to give up, eventually that magical exponential growth will kick in.
Anyway, enough ranting, times to lead some peaceful orcs to defend their homes, yes?
I am working as a “programmer analyst” at the Faculty of Arts, University of British Columbia. I try to take my job title as literally as possible, so I function as a “0.6 programmer” and “0.4 of everything else: idea driver, usability analyst, and architect.” I want to help shape and promote products that are useful and attractive, regardless whether I am the programmer or not. I did an M.Sc in Human Computer Interaction to learn the basics of usability, then continuously adapt the theories and wisdom learned at school to the realities of my work environment and the projects that I’m in.
My current position allows me nearly complete ownership and freedom in a (few) “experimental” educational technology projects, an advantage of smaller organization size. The challenges of smaller organization size are many: limited funding, convincing various levels of management and early adopters that certain ideas are worthwhile, growing a user base quickly (enough not to be defunded), and implementing the actual technology to a high enough level of quality. Overcoming these challenges yielded many, hopefully entertaining, stories to tell.
As this blog can be informal and rambling at times, please visit ca.linkedin.com/in/thomasdang for my condensed professional profile.
# On your own computer (client machine), go to the .ssh folder of your home and generate the key
ssh-keygen -b 2048 -t rsa => enter a passphrase (nice to have)
# Copy the new public key to the server
# many systems especially macs don’t have ssh-copy-id
# and scp may overwrite previous content of authorized_keys on server
cat ./id_rsa.pub | ssh email@example.com “cat >>~/.ssh/authorized_keys”
# Go onto the server, you will still need to enter a password here
# Make sure that the key and .ssh folder on the server is secure enough
# Many ssh client will not let you through if the permission is too open
chmod 700 .ssh
=> the result of “ls -latrh | grep .ssh” should be “drwx——. 2 you you 4.0K May 29 16:21 .ssh”
chmod 600 authorized_keys
=> the result of “ls -latrh | grep authorized_keys” should be “-rw——-. 1 you you 400 May 29 16:31 authorized_keys
# Logout, you are done! The next time you log in again you will not need a password.