Switch between Playback Devices on Windows using a hotkey

August 9, 2014

I got my windows machine hooked up both to my work station, which means an LCD and regular speakers, and to my TV. When I play something on my TV, I want my sound to go through the HDMI and play from my TV speakers. Now, the way to do this is on most windows versions is to right click your speaker icon in the taskbar, choose Playback Devices, and mark your TV as the Default Playback Device. Vice versa when you want to switch back to your PC speakers.

This isn’t very comfortable if you’re sitting on your couch 🙂

AutoHotKey to the rescue!

What you wanna do is:

1) Install AutoHotKey (http://www.autohotkey.com/)

2) Open notepad, copy paste the following code into it and save it as an .ahk file:

ScrollLock::
toggle:=!toggle ;toggles up and down states.
Run, mmsys.cpl
WinWait,Sound ; Change “Sound” to the name of the window in your local language
if toggle
ControlSend,SysListView321,{Down 1} ; This number selects the matching audio device in the list, change it accordingly
Else
ControlSend,SysListView321,{Down 2} ; This number selects the matching audio device in the list, change it accordingly
ControlClick,&Set Default ; Change “&Set Default” to the name of the button in your local language
ControlClick,OK
return

(You’ll notice I used the ScrollLock key as the hotkey. You’re welcome to change it to whatever you like obviously)

3) Double click the .ahk file. This will enable it until your next restart (probably need to autorun it at startup for convenience. Never got around to doing it since I so rarely restart my machine).

4) Double click on ScrollLock and watch the magic happen 🙂

 

Enjoy!


My experience in the Google ̶̶S̶w̶e̶a̶t̶s̶h̶o̶p̶ Workshop

November 20, 2011

I recently attended GDD 2011 (Spoiler alert: the Android Ice Cream Sandwich OS has some nifty features. Beam for instance), which took me down memory lane and reminded me of the Google workshop I attended during my CS BA studies, back in 2010. I posted a link to our project in this blog.

not available for iPhone

The ‘workshop’ is a project every CS graduate from Tel-Aviv University is required to complete. You usually have a choice of around 10-20 workshops (there are more workshops during the 2nd semester), with workshops varying from creating a small robot which will be able to traverse an obstacle course (with a real robot), to more complicated optimal-path finding algorithms, computer vision related projects, machine learning, various mobile-based applications and much more. A relatively new workshop that was available was the Google workshop.

Obviously it was in great demand for having ‘Google’ in its name (the TAU method of getting the courses you want each semester is based on a bidding system. You receive points according to your XP, i.e. how many courses you already completed, and then use those points to bid on courses).

After talking with some of my classmates who completed other workshops, I realize that the Google workshop was one of the only workshops that placed emphasis on Milestones. Milestones were meetings we had about once a month, during which each team held a 15-20 minutes presentation, first discussing its project, and later on its progress on what it promised to complete by that milestone, as well as what we intend to complete next (our objectives). In most other workshops the groups met a couple of times when the semester began, and then the professor pretty much left you alone until you were required to hand in the project at the end of the semester, usually a couple of months after finals ended.

Looking back on it now, the Google workshop, in many ways, prepares its students much better for the scary ‘outside world’. As a programmer you need to be able to write elegant code, but also to give proper estimates as to how long it will take you to write that code. Give an ‘easy’ estimate (“Create a ‘contact us’ form? Oh, about a month’s worth of work”) and you’ll quickly be marked as an inefficient worker. Provide a ‘hard’ estimate (“Design the application’s database? I can whip that up in a day!”) – and it’ll quickly backfire on you. Just like goldilocks, you have to find that sweet spot in the middle. As someone with little or no experience that might prove difficult, but no one said it would be easy.

Another real-world aspect of the workshop was that we got very little ‘references’ from the team. That might seem unfair, unprofessional or perhaps plain old cruel, but in reality – it isn’t too far off from what you’ll face when you start working somewhere. Sure, there’ll probably be more experienced developers on your team who could offer you pointers, and if it’s a big company it might even have an organized system of training new recruits, but your autodidacticism skills will always be put to the test.

We also had to decide how to implement everything ourselves, even in terms of which platform to use. For instance, the workshop instructors introduced us to GWT (when I say introduced I mean that they let us know of its existence and where we can read about it), but didn’t require us to use it. If you haven’t heard of GWT, I recommend reading a little bit about it. It’s an interesting concept. I currently develop using the GWT platform, and I believe it is here to stay. I might even write a post about it soon (if I get around to it). We eventually opted against using it, and I’m pretty sure it was the right thing to do (it was probably “over-kill” for our purposes). But had we chosen to use it, and were to fall behind on our schedule as a result – we would have to face the consequences, or pull very long all-nighters. We couldn’t blame the instructors if it turned out that GWT was unsuitable for our purposes. It was our responsibility to properly research the technology we chose before using it.

Like I said, our workshop conditions were somewhat more difficult than that of the real world, but like we say in the IDF: “Kashe Ba’Imunim, Kal Ba’Krav”, which translates to “The harder the training, the easier the battle”, or to quote General George S. Patton – “Pressure makes diamonds”.


Clientside JavaScript goodness

July 29, 2011

As part of the hiring process to a certain company, I was asked to create a basic RIA (Rich Internet Application), with the primary focus on the client side (there doesn’t even have to be any actual communication with the server – all data can be created as mock data inside the js). Feeling a bit inspired, I decided to document how I went about it. First off, the assignment stated that if I use HTML5 for storage, I’ll get bonus points. I think I should lose points for using it, since it appears it’ll make my life so much easier. HTML5 allows you to save data on the client end, either for the current session (i.e the current window/tab) or for the entire time the user’s browser is open (i.e. across all pages in your domain). No need to send data back to the server or use other hacks. Yes, a cookie does the exact same thing, but a cookie’s “destiny” (and as a result – its size and robustness) is to save small stuff, like preferences or a user ID (which entails going back to the server for additional data. Every time, on every page). HTML5 lets you save almost any data structure inside a mapped data structure (a dictionary). Now obviously this raises quite a few security concerns. But you just have to think a bit about what you decide to save on the client side. Since this is a “mock” project, that will not be an issue. So first things first, let’s set up a quick web site. I’ll use Google WebAppEngine – it’s fast and easy. So you can see what I did here. We also need somewhere to host the code. Google to the rescue once more. Since my server side is going to be meaningless (I only load static HTML pages, with no content provided from the server), I better see how to configure app.yaml so it’ll route my urls properly:

application: apple-of-israel version: 1 runtime: python api_version: 1 handlers: – url: /stylesheets static_dir: stylesheets – url: /static static_dir: static – url: /js static_dir: js – url: /index static_files: static/index.html upload: static/(.*) – url: /employees static_files: static/employees.html upload: static/(.*) – url: /.* script: helloworld.py

this configuration means that when I navigate to localhost:8080/index – I get referred to my index.html file. The same for employees. For now I left the helloworld routing – which means that localhost:8080/ routs to a phython script, which prints an html of hello world. I could have used that routing to create my html in python, but that just seems silly, and also defeats the purpose of taking the load off the server and having the client do all the work. The static redirection is needed for hrefs inside the html pages that link to other static html pages in the site. The stylesheets redirection is needed for when my html pages request the css file inside the stylesheets folder. “Which css?” you ask? The one I got for free here. The js folder routing is for javascript files. obviously. OK, let’s attempt and store some data between pages using our newfangled HTML5. We’ll add this code to index.html:

<script type=”text/javascript”>

sessionStorage.setItem(‘userName’, ‘tom’);              // defining the session variable

alert(“Your user is: ” + sessionStorage.getItem(‘userName’));   // accessing it

alert(“Hello ” + sessionStorage.userName);                   // another way of accessing the variable

</script>

and the following code to districtNorth.html:

<script type=”text/javascript”>

sessionStorage.setItem(‘userName’, ‘tom’);              // defining the session variable

alert(“Your user is: ” + sessionStorage.getItem(‘userName’));   // accessing it

alert(“Hello ” + sessionStorage.userName);                   // another way of accessing the variable

</script>

Well, that was pretty easy. So I am now able to move around different static HTML pages, and I also have a local datastore. Awesome. Time to create my mock data, find some cool javascript libraries and start using and manipulating that data. Well, the mission mostly required me to display a list of people who pick apples in different sectors of Israel. The actions which a user could perform were listed. So naturally, I started with creating mock data of bunch of apple pickers.

Late edit – due to having to finish the task on time, I kinda stopped writing about what I’m doing at this point. For some reason I haven’t published this post right away (probably felt ashamed at not documenting the entire process).

also , if anyone is interested in knowing – I got the job 🙂


Why do we dream?

February 20, 2009

Some people claim that our dreams are the manifestations of our subconscious, i.e. the brain’s way of telling us what we “really want”. However, I see no logical reasoning behind this claim. In reality, I think it mimics the same way of thinking that leads to religion, astrology, new-age “medicine”, and the likes – human beings like to “personify” things. This claim is explained in Richard Dawkin’s book, the God Delusion.

When giving our dreams meaning, we personify our brain, giving it a separate entity from our own, believing that it somehow “guides” us in our life, bestowing on us its “mystic” wisdom. It is a comforting thought, since it provides us with hope that there is a bigger plan, or that we have a guiding force in our life, a guardian angel if you will, that watches over us and guides us. I see it as a romantic idea, wishful thinking. A human need.

However, scientific doctrine aims to remove humans from the equation, reaching conclusions which do not rely on the human observer. Therefore, if there is no logical explanation for this subconscious, which (or maybe I should say “who”?) tells us what we should do with our life, but only through dreams that we need to interpret using unscientific methods, i.e. intuition, I must look for an explanation which relies on known scientific axioms.

An axiom which immediately comes to mind is evolution.

evolution

I will not go into the whole evolution vs. intelligent design debate, since you can find plenty of websites which discuss it, and since frankly I could just as well debate evolution vs. the Flying Spaghetti Monster.

If you “believe” in evolution, and more importantly, if you understand it, you realize that each living organism on this planet looks the way it is today since, quite simply, all the other ways were not good enough. In other words – its current state is dictated by whichever changes that allowed it to survive better. This survival is not an inner mechanism or something that drives it. There is no “force” which makes evolution exist. Things which are best suited to survive do just that because they are best fitted to do so. Kind of recursive 🙂

So let us go back to the title of this blog entry – “Why do we dream?

dreaming_toc

I offer an evolutionary point of view, combined with computer science thinking.

The human brain is composed of connections. The more we think in a certain way, the more certain connections become stronger, reinforced. That is why astronauts undergo extensive underwater training before going on missions. It takes time for the human brain to adjust to new points of reference in space. Astronauts in microgravity usually lose their sense of direction and feel uncoordinated or clumsy. Because inner ear and muscular sensors seek terrestrial clues, astronauts must learn to rely on visual cues for balance and orientation. But even visual cues can be confusing – astronauts in microgravity need to adjust to the fact that up and down don’t really matter in space like they do on Earth. They need to “force” their brain to think differently, and that takes time.

The same goes for human emotions. If for example you are a person who is always depressed, you will not be able to change overnight. Changing your way of thinking and behaving will take time, since you are “re-wiring” your brain (however, if you want a “quick fix”, you can always get a brain pacemaker transplant – http://en.wikipedia.org/wiki/Brain_pacemaker). The more you think differently, the more these connections become stronger, and the other become weaker. It is a very elegant code if you think about it from a programming point of view. It makes itself more efficient and streamlined, according to the relevant needs. Human emotions might not relate to evolution so clearly, but if we consider other brain functions such as moving about, breathing, or recognizing a lion in the bushes – it is vital for our survival that we carry out these actions successfully and as quickly as possible. Our brain has evolved in a manner which makes sure that whatever we do the most – i.e. whatever we need to do to survive more, we do as efficiently as possible. Assuming of course that whatever it is that we do the most is beneficial for our survival – perhaps not so true in the 21st century (for instance, I don’t think that reading this article improves your chances for survival, although I’ll be flattered if you think so), but most definitely true in most of our evolution, which took place in the wild, in much more harsh conditions.

lion31

[peek-a-boo]

So the connections in our brain constantly grow stronger in various ways, according to what we do and how we think. It has been known for quite some time that the augmentation of these connections mostly happens when we sleep, as corroborated by a recent study (http://www.eurekalert.org/pub_releases/2008-01/uow-sbc011808.php). This is known as plasticity (http://en.wikipedia.org/wiki/Neuroplasticity). It also makes sense – as every person with a computer knows – it isn’t very smart to install/uninstall computer programs while they are running.

So why do we dream? Well, my hypothesis is that our dreams are a “system-check” carried out by our brain. When you go to sleep, your brain shifts synapses in your brain, making some connections stronger, some weaker and perhaps even creating new connections or completely severing old ones. After making each change – it is a good idea to run a system-check, don’t you think? That is also why our dreams seem so real. As far as we are concerned, the messages in our brain when we dream are identical to the ones we get when we are awake – or else it wouldn’t be a very good systems-check, now would it? Also, that is why dreams relate to memories – that is the information the brain has available to use for its systems-check. Furthermore – dreams usually relate to recent events, since those are usually the areas which get modified.

But the most important part in my hypothesis is why I think my argument is true. After all, I can find lots of explanations for why we sleep, why is mine more logical than the rest? Well, I suggest that this systems-check is a direct result of evolution.

Consider that our brain evolved, and we started making more and more connections. Obviously, these connections were augmented in our sleep, since if you started making changes in your brain while you are awake and running away from a cheetah – well, let’s just say your survival chances were not very good.

But some individuals also started having dreams. Those dreams were the systems-check carried out by their brain, making sure that all of these new connections were OK.

So those who had dreams one-upped their fellow tribe-members evolutionary-wise. They had less chance of suffering the consequences of “faulty-wiring”. And we all know how one bug in a program can wreak havoc…

blue_screen_of_death1