After finding out about this method of programming, I immediately began looking for ways to use it in my life. For me the most obvious use came the next day, when I was playing a game with some of my friends. The idea was to get to a certain Wikipedia page in the fewest number of clicks. An example of getting from Pair Programming to Marie Antoinette would be Pair Programming > Programmer > Offshore Outsourcing > China > List of Countries and Dependencies by Area > France > Louis XVI > Marie Antoinette. Of course, there are likely many many many other networks that lead from Pair Programming to Marie Antoinette. The challenge is to find the shortest one. And this task seems far more suited to a computer than a human. A computer can iterate through thousands and thousands of links in seconds, searching for answers. It would be ideal to use one to solve the Wikipedia game. For two specific articles, it might take the computer minutes to find the optimal solution, learning through trial and error which pages it should take.
Sunday, April 5, 2015
Machine Learning
When I went to UT Austin for a college visit, they had one of their best professors give us a lecture on Machine Learning, specifically in soccer playing robots. His lab had developed a method of getting the robots to teach themselves how to run the fastest, or kick the ball the furthest. It was all based off a simple process. First, one needed to define the parameters for success. For some algorithms, this was just as simple as a for loop looping through a parameter, and testing the program each time. When the parameter was finally maximized, we have finally allowed the machine to teach itself a behavior. This is one of the best ways of programming, because the program will always run optimally, given enough time.
Saturday, April 4, 2015
The Button: A Peek Into the Technology That Has Captivated Half a Million People...and Counting
Reddit.com is a social media site infamous for its silly April Fools jokes. In 2013, they announced a collectible hat trading game on the site, that split the site into two competing camps. In 2014, they announced Heddit, where users could perform site actions with their face. (Frowning, for example, down voted content.) This year, however, Reddit's joke was much simpler. It was the creation of a subreddit, /r/thebutton, which consists of a one minute timer, ticking down to 0. The aforementioned button is right next to it, which resets the timer to 60.00 whenever someone clicks it.
The subreddit has become a sort of game for thousands of people, who eagerly speculate about what will happen when inevitably, the button hits zero. In fact, the frenzy has separated redditors into two camps: those who wish to keep the joke alive as long as possible, pressing the button to prolong the agony of others, and the non-pressers, who await the moment who the clock hits zero. The speculation is almost laughable over something so simple. In this blog post, I'll be examining the technology behind the button that has captured the time of so many people.
Everything is captured in these few lines of code.
The three integral parts of the page are the button, the counter, and the chart. The button itself is coded simply as a div, "thebutton-container locked active". The script tags below it are responsible for the chart and the count down, they link to google's visualization apis which allow reddit to display their tantalizing counters and the count down chart. Nothing really new there. The html code of the site is actually being updated in real time as more and more people are clicking on the button: the span "thebutton-participants" is changing in real time as people click the button. Here, I've come to a conclusion. Nothing special will happen at 0 seconds. The code simply shows that at 0 seconds, the site will hang, waiting for unsuspecting prey to click the button once more.
PS: During the course of research for this article, the author quite unfortunately (and by accident) clicked the button...at 58 seconds.
Wednesday, April 1, 2015
SSH Tunneling
I think AISD is taking the wrong approach by restricting the internet at school. The content filters at school often get in the way of students who are looking to do actual work. Recently, I've run into a ton of restrictions while trying to complete assignments. It seems as if AISD is simply restricting more and more, and not checking their own policies. For example, recently, I was trying to create the game tic-tac-toe in javascript. However, every time I looked up tutorials, I found myself blocked by the "this site contains games content" filter. Another example would be the time I was working on a project for Great Ideas on Gender Discrimination in Primetime TV Shows. I found myself unable to look up even plot summaries of TV shows at school, because AISD was being paranoid. Control over what students do in class should be given to the teachers, and not blanket banned by the district.
A common solution to these problem would be the use of proxies or TOR, but both are blocked by the ever vigilant AISD. A solution that I think might work would be SSH Tunneling. It creates a secure "tunnel" between your network and another client, which allows a user to do things as the other computer. It's really useful for network administrators, who often need to securely access a remote server and run commands from that server. It can also be used as a form of secure file transfer, using the tunnel to transfer not only data/commands but also files. But the part that may be most applicable would be its use as a proxy. Since the user is routing traffic through another router, they are able to access the internet through the unblocked router.
An SSH tunnel is one of the best ways to bypass a firewall because it's difficult to block. Since many network administrators use SSH tunneling themselves, most organizations choose to not block that vital port, and thus using SSH as a proxy works.
A common solution to these problem would be the use of proxies or TOR, but both are blocked by the ever vigilant AISD. A solution that I think might work would be SSH Tunneling. It creates a secure "tunnel" between your network and another client, which allows a user to do things as the other computer. It's really useful for network administrators, who often need to securely access a remote server and run commands from that server. It can also be used as a form of secure file transfer, using the tunnel to transfer not only data/commands but also files. But the part that may be most applicable would be its use as a proxy. Since the user is routing traffic through another router, they are able to access the internet through the unblocked router.
An SSH tunnel is one of the best ways to bypass a firewall because it's difficult to block. Since many network administrators use SSH tunneling themselves, most organizations choose to not block that vital port, and thus using SSH as a proxy works.
Commenting Code
After my last blog post about why I stopped doing research, I thought I'd take a blog post to discuss one of the major reasons I quit the project: a lack of comments. Before starting the project, I thought it was unnecessary unless I was working with others. However, I quickly found that I forgot what my code did after a couple months. The problem was the sheer scale of the project. I was working with five or six different functions, each with their own inputs and requirements. Every time I wrote new code, I found myself writing new functions to accomplish tasks I already had functions for.
for(i in 1:length(seasons)){
if(trim == FALSE){
loop.var <- 1:length(unique(seasons[[i]]))
}else{
loop.var <- 2:(length(unique(seasons[[i]]))-1)#the first and last season are not full seasons, so you may want to exclude them
}
for(s in loop.var){
sea.s<-unique(seasons[[i]])[s]
use.s<-which(seasons[[i]] == sea.s)
goal.s<-goal[-use.s]
clinics.s<-clinic_data[-use.s,]
m.s<-lm(goal.s~clinics.s)
#which coefficients aren't na?
use.coef.s<-as.vector(which(is.na(m.s$coefficients[-1])==FALSE))
#out of sample prediction
pred.out<-m.s$coefficients[1]+rowSums(as.matrix(clinic_data)[use.s, use.coef.s]%*%as.matrix(m.s$coefficients[-1][use.coef.s]))
oos[use.s,i]<-pred.out
#checks for infinity
if(sum(goal[use.s])==0){
R2Out.i <- NA
}else{
R2Out.i<-1-(var(pred.out-goal[use.s])/var(goal[use.s]))
}
R2Out[use.s,i] <- R2Out.i
R2In[-use.s,i] <- summary(m.s)$r.squared
}#end for s
}#end for i
Here's an example of some code that I wrote, with comments delineated by the # marks. The first comment, "the first and last season are not full seasons, so you may want to exclude them" doesn't explain the code effectively, but rather indicates an option. This in itself isn't a problem, but without further commenting, it becomes very difficult for anyone to understand what my code does. The following two comments are much more useful: "#which coefficients aren't na?" and "#out of sample prediction". I shied away from more of these line-by-line explanations because I didn't want to have to include comments on every line of code. However, now I think that the line-by-line commenting is necessary for me to understand my own code. In the future, that's what I will do.
for(i in 1:length(seasons)){
if(trim == FALSE){
loop.var <- 1:length(unique(seasons[[i]]))
}else{
loop.var <- 2:(length(unique(seasons[[i]]))-1)#the first and last season are not full seasons, so you may want to exclude them
}
for(s in loop.var){
sea.s<-unique(seasons[[i]])[s]
use.s<-which(seasons[[i]] == sea.s)
goal.s<-goal[-use.s]
clinics.s<-clinic_data[-use.s,]
m.s<-lm(goal.s~clinics.s)
#which coefficients aren't na?
use.coef.s<-as.vector(which(is.na(m.s$coefficients[-1])==FALSE))
#out of sample prediction
pred.out<-m.s$coefficients[1]+rowSums(as.matrix(clinic_data)[use.s, use.coef.s]%*%as.matrix(m.s$coefficients[-1][use.coef.s]))
oos[use.s,i]<-pred.out
#checks for infinity
if(sum(goal[use.s])==0){
R2Out.i <- NA
}else{
R2Out.i<-1-(var(pred.out-goal[use.s])/var(goal[use.s]))
}
R2Out[use.s,i] <- R2Out.i
R2In[-use.s,i] <- summary(m.s)$r.squared
}#end for s
}#end for i
Here's an example of some code that I wrote, with comments delineated by the # marks. The first comment, "the first and last season are not full seasons, so you may want to exclude them" doesn't explain the code effectively, but rather indicates an option. This in itself isn't a problem, but without further commenting, it becomes very difficult for anyone to understand what my code does. The following two comments are much more useful: "#which coefficients aren't na?" and "#out of sample prediction". I shied away from more of these line-by-line explanations because I didn't want to have to include comments on every line of code. However, now I think that the line-by-line commenting is necessary for me to understand my own code. In the future, that's what I will do.
An Update Concerning Research, Or, Tact and Diplomacy
This semester, the one avid reader of my blog may realize that there recently has been a severe dearth of posts concerning research: the most common topic of my first semester posts. The astute reader may wonder why this is. After all, this research was one of the most interesting things I did--it went on every college application, gave me something outside of school to do, and was the first taste of a job I had ever had. The problem was one of time. Whether it was poor time management, or simply the fact that I wanted to enjoy senior year, I found myself completing less and less work as the year dragged on. Last summer, I was completing an assignment every week. Last semester, it dropped to an assignment every month. Finally, this semester, I have yet to do anything significant for the project. And the problem just snowballed. The less I worked with my code, the less I understood it, and the less I was able to work with my code. The experience at the very least taught me the importance of commenting code.
The hardest part of the entire process was letting the professor and the grad student know that I was stepping out of the project. I realized that I couldn't juggle both the demands of school and the demands of research in February. Still, I only took the time to draft the email a week ago, and finally sent it out today.
I learned a lot from research, and not just about computer science. Still more important, I believe was the chance to interact with others in a professional setting, and to make horrible blunders like not communicating for four months. These are things better done in high school than at a first job.
Subscribe to:
Posts (Atom)