The reality of tech legislation.

As a software engineer, I can assure everyone that legislation like what the President has proposed to address the recent Sony hack won't solve the problem; rather it is likely to exasperate the issue.

Sony gets hacked because they painted a bullseye on their back when they decided to sue ethical hackers. Also Sony is notoriously known within the tech industry for being a mismanaged, segmented company with non technical leadership. Which means that the engineers they tend to hire, aren't the best, because the best decide to work at the best tech companies. (e.g google, apple, facebook, etc), which this results in a situation where Sony software is shitty with very little motivation to fix security issues.

In the past, I have been involved with both Sony's official closed beta developer forums directly and hacker communities who specialized in ps3 homebrew development. There have been times where we in the hacker communities had discovered vulnerabilities in their psn infrastructure like using a severely outdated version of the Apache webserver that had been flagged with a high risk vulnerability years prior to the first time PSN was hacked presumably by Lulzsec.

We actually did the ethical thing and tried to get in touch with Sony to discuss these vulnerabilities because we were concerned that their entire network (and consequently their entire userbase) could be compromised. I know personally that the emails I sent either didn't get a response or any response I did get back would be "we will look into it" and apparently they didn't; because it wasnt long after this that PSN was hacked.

The thing is, I am scared to even talk about this with the public because the laws government passes regarding computer security, fraud, and intellectual property rights doesn't do enough to protect me personally from being labeled a hacker vulnerable to criminal prosecution and civil lawsuits.

Legislation won't stop hackers from hacking. In fact it will only entice it because it leads to cases like the government's legal persecution of Aaron Schwartz. This gives hackers a cause to fight against just like drone strikes that demolish entire Afghan villages gives a cause and initiative for terrorist organizations like ISIS and Al Qaeda to retaliate against us (those of us in western society that is) where we live. It's the never ending back and forth cycle of blowback. There are "forces of evil", ethical government must fight against, but the ethicality of a government is concisely decided by how and what they identify as a " force of evil" and how to address the best way to conquer the foe with minimal "civilian casualties".

Right now, congress isn't competent enough to properly address issues regarding technological issues. So I strictly stand behind a position that I won't try to educate politicians in the art of acquiring votes if they don't try to mandate the way I can design tech.

Y-Combinator

While I cant speak from a perspective of personal experience regarding participation in ycombinator; I am currently prepping myself and my idea for this upcoming summer event; and I do think I have a bit of useful advice to offer other founders who are (much like myself) aspiring to not only get their startup idea accepted into ycombinator; but ultimately end up with an outcome where they receive the funding necessary to kickstart their business. So I am just going to list of a few principles I believe are most important to maximize the chances of success in ycombinator that you should get down before a founder should even consider applying.

1. Do your homework.

(I) There are a ton of books and blog posts that I highly recommend founders read before they consider applying. Here is a list of the books I am currently reading and why I think they are so important.

(A) The Steve Jobs biography.

First off, This book is a fantastic read; plain and simple. I'd recommend it to someone who didn't understand a thing about tech just because how fascinating the story of Steve Job's life was.

Now as my recommendation pertains to aspiring entrepreneurs, Even if you aren't a fan of Apple's products and/or Steve Jobs (i.e his philosophies, his personality, w/e); only a fool would say Job's wasn't one of the greatest founders to ever live. His story is a keen example that demonstrates the best AND worst qualities of a founder. My short summary of the most important message you will get out of this book is thus:

Success is produced by strong, passionate leadership that can maintain a well balanced sense of self-conviction when it comes to mandating the set of core values they believe will pave the way that brings their vision into fruition.

For Steve Jobs, his up and down battle with his self-conviction made him a great leader because he refused to compromise on his vision on what Apple should stand for; but at times it made him a bad leader because he was inclined to alienate people and ideas that didn't integrate into his volatile, constantly evolving black and white views of the world.    

There is a fine line between a rational reality and an irrational one; and when people refer to his "reality distortion field" effect, I think it is misleading to label of it that way because it seems to paint him as a snake-oil salesmen. Rather I think he just had a cunning way to point out when our perception of what's possible is being biased by our flawed perception of how we interpret the divisionary line that our sense of rationality projects.

(B) Business Adventures

Bill Gates turned me onto this book in one of his Gate Notes post. Its a bit dated (the copyrights are dated from 1959-1969) so its stories aren't 100% relevant to today's world (e.g there is a story about the stock market freaking out because stock updates back then could get overloaded and jammed because updates to a stock was communicated by a computer printing output via paper tape); however with that being said, the core morals and points addressed in the book regarding good vs bad business (e.g. marketing, product design, brand awareness, technological limitations, etc) is pretty enlightening, entertaining, and perhaps even motivational because there are stories that show that even the most successful companies and business savvy entrepreneurs experience epic fails from time to time.

(C) All the books and articles Y-Combinator recommends at http://ycombinator.com/resources

I have only started diving into these books and articles, so I can't say much about my experience reading them, however I have read a bunch of Paul Grahams blog posts; and I can say they are quite entertaining. (Though I dont always agree with his opinion, I do find his perspective on things interesting to ponder about.)

However, even though I haven't read them yet; I still recommend them because the key purpose of Y Combinator (imho) isnt to help get your startup buzz and financed; rather the key purpose is to teach founders how to turn their grand vision into a successful company. Everything else that happens at Y-Combinator, (investor meetups, articles of incorporation, press exposure etc) is just them helping nudge startups out to sea. If the startup's crew doesn't know how to properly set the sails on boat before they undock the startup wont get anywhere anytime soon. (which leaves the startup vulnerable to mutiny, sinkage, spoiled and/or depleted resources, etc)

If you are a founder applying for ycombinator, and you (and your other founders) haven't read all of the recommended reading yet (or even worse don't plan on it), you aren't doing one of the most important things you need to do as a founder to succeed; putting in the work that mitigates risk of failure.


(D) cat-v considered harmful
This is a paper written by Rob Pike that made me a better engineer by several orders of magnitude.

It really opened my eyes to the inherent beauty and elegance to the concept of simplicity. If you haven't yet come to this revelation I implore you to read the article and ponder on this quote.

"Simplicity is the ultimate sophistication" (quote origins disputed but many attribute it to Da Vinci)

If you look at many of the most successful products out in the market one trend that should be the most apparent is that the most elegantly simple and fresh products with the best marketing tend to win. That's why fast food is so successful. That is why iPhone was a smash hit. That is why Google Search is a billion dollar company. That is why facebook beat myspace. That is why Starbucks is successful even though they charge 2000x markup on what it would cost to brew your own coffee at home when you wake up. If simplicity isn't something you incorporate into every aspect of your business, a competitor will pop up that does, and they will gobble you up like Pacman on power pills.

http://harmful.cat-v.org/cat-v/

(II) Videos worth watching.

(A) How To Start a Startup

The reasoning for this recommendation is the same as the reasoning I stated above regarding the ycombinator recommended reading. (since this is the ycombinator sponsored standford class)

https://www.youtube.com/channel/UCxIJaCMEptJjxmmQgGFsnCg
http://techcrunch.com/2014/09/16/y-combinator-will-teach-a-class-on-startups-at-stanford-this-fall/

(B) Alexis Ohanian - Making Something People Love.

Considering that Alexis is a Y Combinator "O-G", I probably don't even need to try to explain why I recommend this for founders; but I'll go ahead and give my two cents out of respect.

If I had to narrow down the number 1 trait thats makes Alexis an extremely great founder in my mind, I'd have to say it's his overwhelming sense of compassion for people and that compassion is reflected into the products he helps build. If I were to take a guess at the reasons Paul Graham asked Steve and Alexis to come back to discuss a new idea after rejecting their "MMM" (my mobile menu i believe?) app, I would assume that Alexis' and Steve's compassion and ambition to build something users love, played a big part in that decision.        

One of the most important lessons I took away from this video (and other talks given by alexis) was that if I didn't feel personally compassionate enough about my startup idea, it is probably not the right idea for me to submit to Y Combinator and attempt to pursue.  

https://www.youtube.com/watch?v=KKYkmYuk5l8

(C) Public Static Void
Here is another rob pike related recommendation that discusses over complexity in technology.

https://www.youtube.com/watch?v=5kj5ApnhPAE

2. Know which technologies to invest in.

(I) Recruitment

One of the biggest challenges in building a successful startup is finding the best engineers, and in my opinion the best engineers tend to flock to the state of the art tools that make their lives easiest. Current trending technologies that come to mind that are worth investigating (imho) are tools like...

(A) CoreOS
CoreOS is a great OS because it is built around the premise that your web service will grow in traffic and at some point your service will have to scale and run seamlessly on more than one system. (hardware or vm)

In my views, I think it is best to build web based apps from the ground up under the premise that one day your app will handle millions of page views a day. Its easier to build for scale at the beginning, rather than realizing 2 years down the road that whatever technology you are using now just can't scale to satisfy your app's heavy traffic load anymore.

https://coreos.com/

(B) Go or Rust

This recommendation will probably spark a holy war debate, but regardless of how you feel about the languages, the fact is that when it comes to finding the BEST engineers; they tend to WANT a job where they can use one of these language. Of course, they are in short supply so you might be more fortunate finding a Ruby, Python, or Scala developer.

But there are technical flaws to consider in all languages, and it is important to consider a language that will satisfy your needs now and later down the road.

http://blog.iron.io/2013/03/how-we-went-from-30-servers-to-2-go.html

3. Research the market you are trying to enter/create.

(A) Think about how to generate revenue from day 1.

I am personally not a big fan of the whole, "focus on getting users now and worry about generating revenue later" philosophy that seems to be a popular trend in startups nowadays. I personally believe that there are huge opportunities to innovate how revenue is generated in web based applications, and I believe opting out of thinking about how your app will generate revenue until later, is basically a cop out decision to one day just do what every other web based company does nowadays after they gain a significant userbase. (Force ads on them; sell their info to the highest bidder; provide only half of the site to users for free; etc, etc...)

Unfortunately, some web applications are harder to monetize than others; so perhaps advertisements and data mining are the only options for a startup. However, that doesn't mean founders shouldn't consider take into consideration the potential for innovation when it comes to how their product generates revenue.

(B) Your idea doesn't need to be 100% original. It just needs to be 100x better than the competition.

John Graham-Cumming, "Turing's Curse"

https://www.youtube.com/watch?v=hVZxkFAIziA

If you watch this video, it becomes immediately clear that the term "innovation" in tech is nothing more than something we say when we upgrade our wagons from wooden spoke wheels to tires with 20 inch spinner rims.

Your idea doesn't need to create a new market to win big, it just needs to be better than whatever currently exists.

Apple didn't create the personal computer market, they just made a product that was 100xs better than it's competitor's products.

http://en.wikipedia.org/wiki/Microcomputer#History

Google didn't create the search engine market. they just made a product that was 100xs better than it's competitor's products.  

http://en.wikipedia.org/wiki/Web_search_engine#History

The list goes on and on and on and on and on.

I think everybody here has heard the Picasso quote that Steve Jobs' has stated on numerous occasions.

"Good artists copy, Great artists steal"

Many people believe Steve Jobs is a hypocrite for using this quote and later trying to sue Microsoft and Google for patent infringement; and in my opinion they just don't understand what Picasso meant by using the term "steal".

The best example I know of that makes Picasso's quote crystal clear is quote Trent Reznor gave regarding his impression of Johnny Cash's cover of his song "Hurt".

http://en.wikipedia.org/wiki/Hurt_%28Nine_Inch_Nails_song%29#Background

4. just a quick aside regarding another Steve Jobs quote that I find rather interesting to ponder about.

When steve presented the Macintosh he described it as "Insanely Great"; which is a bit ironic because one of the very few pieces of furniture he kept in his house at that time was a portrait of Albert Einstine, who once said,

"Insanity: doing the same thing over and over again and expecting different results."

The reason I find this ironic stems from the fact that Steve Jobs obtained the inspiration for the Macintosh's GUI from a deal made with Xerox where they agreed to show him and his team a demonstration of the technology they developed for their Alto Computer in exchange for a stake in Apple. However after Xerox demoed the Alto to Apple, they tried to commercialize the technology and beat Apple to market with a workstation they developed soon afterwards called the Xerox Star; which was a total commercial flop. I wonder if Steve deliberately called the Macintosh "insanely great" as a way of paying homage to Einstein while taking a jab at the Xerox Star?

The "Net Neutrality" fallacy.

As a software engineer, I find it very depressing that we live in a country where "net neutrality" debates have become a necessary step we need to take before the process of technological advancement can resume. The reason I say that is because the idea of "net neutrality" wouldn't be a topic worth debating if we lived in a country that had a national, state of the art, internet infrastructure rather than the pathetically slow, data capped, overpriced shit we have now.

The ISPs idea of introducing "fast lanes" into their network infrastructure is a deliberately malicious scheme inspired by greed. The ISP's should consider it an ethical responsibility to invest money back into their business infrastructure so they can one day ensure every American home has affordable fiber.

If everyone in America had fiber, all the network congestion caused today by companies like Netflix; would be fundamentally non-existent because it would enable these companies to send their customers a handful of "fat" packets of data, rather than the thousands of little packets they must send now. This would dramatically lower network congestion because the fundamental bottleneck is the fact that data on the wire can't exceed the speed of light and in practice tends to travel much slower than C on average because of the complex circuitry data has to traverse while in route through the network toward it's destination.

Think of it like this. Let's say you had just started remodeling your kitchen and as a result you end up creating a huge pile of garbage after you tore out the old kitchen in order to make room for the new. You know eventually you are going to have to take that huge pile of garbage to the dumps, and that will require a mode of transportation that can haul the trash from point A to point B.

Now, ask yourself this. If you had the option of picking either a small short-bed S10 pick-up truck or a big U haul truck with a 20 ft trailer; as the vehicle used to haul the trash to the dumps; Which choice would be the most logically efficient choice in terms of minimizing the amount of time and fuel that is spent? Something worth noting about the answer to this question is that the logically best choice is dependent on the SIZE of the load.

If the S10 can get the entire load in one trip then it is the most efficient option because it doesn't need to spend more time and gas traveling back and forth because the s10's bed is too small, thus requiring multiple trips to get all of the trash to the dumps. Obviously if we had a huge amount of trash, the uhaul would be the best choice even though it has a far worse fuel economy compared to the s10 because the amount of time spent actually burning that gas is much less time than the s10 ends up having to spend.

Now applying this analogy to data networks only makes the problem exponentially more chaotic because now your entire neighborhood is following your lead and deciding to remodel their kitchens too. Thus they also generate their own garbage piles that need to get hauled of to the dumps.

Now you have a situation where not only do you have to haul your trash from point A to point B, you also have to deal with terrible traffic congestion because the freeway to the dump is 2 lanes too narrow and hundreds of s10s and uhauls are trying to squeeze their way through because they all want to get to the dumps first.

Now, ask yourself this. Is the S10 ever a good choice in this situation? No. Because when you add congestion cost to the formula you are always presented with a situation where s10's that have to take multiple trips are a HUGE burden towards an increase in congestion, because the more time you spend driving on the road equates to the more time you spend being in somebody's way.

Now, given the previous situation where we concluded the s10 would be the most logical choice given a load small enough to haul in a single trip; this also becomes impractical when you consider the fact that a single uhaul could handle your small load, and potentially a few of your neighbors too. You can combine loads together so long as you know how much weight each load contributed to the grand total. (which you need to discern what each neighbor's fair share of the dump fee is.)

One fully packed uhaul that only needs to make a single trip to the dump is always better than 4-5 s10s that also only need to make a single trip when you consider the amount of congestion 4-5 s10s contribute to the network's speed bottleneck.

Now the problem with the "fastlane" ideology is that in our scenario the RIGHT answer to help make everybody's lives better is to widen the freeway to 4-5 lane, because at the end of the day congestion is always going to be the biggest performance bottleneck.

However, the ISPs don't want to do that. They want to build a road off to the side of the freeway that goes straight to the dump and the only vehicles it allows to drive on it are s10s in need of making 10+ trips that day. All so they can charge a toll coming and going both ways each trip the s10s have to make.

The worst part about the "fast lanes" is that it gives the ISPs an incentive to stifle innovation towards America's internet infrastructure because to successfully market the luxury of a "tolled express lane" they need congested double-lane freeways.

A few pointer pointers

 This post assumes the code is executed and the reader is observing the output while reading.

Light Version
Raw Text

package main

import "fmt"

func main() {

 a := 0
 b := 0

 // a and b's address that points to where they are located in memory.
 fmt.Printf("main: &a = %v &b = %v\n\n", &a, &b)

 /*
  Note that when we pass by value, the 'a' declared in foo()'s arguments has a different
  address than the 'a' variable declared in main().

  Which means that we are actually passing in a copy of main()'s 'a' variable.
  Any changes made to the value of foo()'s 'a' will not change the value of main()'s a.
 */
 fmt.Println("[pass by value]")
 fmt.Println("main: before foo(a), a =", a)
 foo(a)
 fmt.Println("main: after foo(a), a =", a)

 /*
  Note that when we pass by pointer, the VALUE of bar()'s argument bptr equals
  the address of main()'s b. Also note that the main()'s bptr address is different
  than the addresses of main()'s b and bar()'s bptr.

  This means that a pointer is just a integer data type that stores an address in memory
  as it's value. When passing a pointer into a function, instead of passing in a copy of the
  variable being pointed to, we pass in a copy of the pointer itself. The new pointer still
  points to the same variable because the pointer's value (the variable's address)
  doesnt change.

  Since a pointer's value is only an integer representing the address of a variable in memory
  we cant directly modify the value of the variable being pointed at, by modifying the
  pointer's value.
  For example, lets say we wanted to increment variable 'b' (b+=1). If we tried,

  b := 0
  bptr := &b // bptr == 0x01000008
  bptr++
  fmt.Println(b, bptr) // b == 0, bptr == 0x01000012

  the value of b wont be incremented when 'bptr++' is called. What actually happens is that the
  value stored in bptr (the address bptr is currently pointing at) will be incremented to point
  to a new contigious block of memory.

  [NOTE: Unlike C/C++, developers arent actually allowed to directly modify the value of a pointer
   using arithmetic in go. Pointer arithmetic is considered an unsafe language feature, therefore
   developers must use go's "unsafe" pkg to manipulate a pointer's value.]

  In go and many other C-like language, accessing the variable through one of its pointers
  requires dereferencing the pointer by prefixing the dereference operator ('*') onto
  the pointer's identifier (e.g '*bptr'). In computer science terms this is called indirection.

  [NOTE: In C/C++/Go/etc, The asterisk symbol ('*') has several semantical meanings depending on
  the context in which it is used. Most developers will be familiar with it's use as the
  multiplication operator. However, for developers unfamiliar with C-style pointer syntax,
  the asterisk is a notoriously common source of confusion when first learning about pointers.
  I assume the reason for this confusion stems from the fact that the asterisk is not only used to
  dereferences a pointer, but to specify a pointer type as well. The confusion is only made much
  worse when the address-of operator ('&') and pointer pointers (i.e. xptr_ptr => xptr => x) are
  thrown in the mix.

  For example, check out this function literal.

  func(b uint32) float32 {
   return *(*float32)(unsafe.Pointer(&b))
  }

  Despite only being one line of code, it's not uncommon for even an experienced go developer
  to require a few moments to fully digest whats going on the first time they stumble upon
  code like this. I assume most developers, who are still new to pointers, will
  find code like this to be intimidating and very difficult to conceptually visualize whats
  going on semantically.

  If you, the reader of this blog post, are struggling to understand
  what this code does. I recommend taking it slow and using the language's spec as a codex to
  decipher what is going on.

  Here is code example to help point you in the right direction.
  http://play.golang.org/p/myunEgQPRG]

 */

 bptr := &b
 fmt.Printf("\nmain: bptr = %v (aka &b), &bptr = %v, *bptr (aka b) = %v \n\n", bptr, &bptr, *bptr)
 fmt.Println("[pass by pointer]")

 fmt.Println("main: before bar(bptr), b =", b)
 bar(bptr)
 fmt.Println("main: after bar(bptr), b =", b)

 /*
  To be continued....
 */
}
func foo(a int) {
 fmt.Printf("foo: a = %v, &a = %v, \n", a, &a)
 fmt.Println("foo: a++")
 a++
 fmt.Printf("foo: a = %v, &a = %v, \n", a, &a)
}
func bar(bptr *int) {
 fmt.Printf("bar: bptr = %v, &bptr = %v, *bptr (aka b) = %v \n", bptr, &bptr, *bptr)
 fmt.Println("bar: *bptr++")
 *bptr++
 fmt.Printf("bar: bptr = %v, &bptr = %v, *bptr (aka b) = %v \n\n", bptr, &bptr, *bptr)
}

Real World Concurrency

The best way to explain concurrency is to compare the different types of concurrent systems that may be found in downtown NYC during a weekday.

Parallelism:
Cars driving down the street next to each other in their own respective lanes demonstrates a parallel concurrent system. The potential parallelism and efficiency that can occur in this system depends on a few significant properties of the current state of environment, specifically;
1. Where the cars are going?
2. How Congested is the traffic?
3. How attentive, polite and in sync is the driver with those around him?
4. How many available parking spaces are there in areas of contention?

The environment is considered an embarrassingly parallel environment if all the drivers
are headed toward their work's individually assigned parking lot space while taking a back road they know will most likely have little traffic during that time of day based on driving conditions information one of the drivers shared with the group.

On the contrary, this parallel system can be very chaotic and inefficient when traffic is packed and car horns are blaring because 10 vehicles are trying to squeeze in and cut each other off so they can take the parking space that is currently being unsuccessfully vacated by a now boxed in car.

Preemptively Scheduled Threads:

This model is best visualized as a set of cars going from point A to point B while hitting a bunch of 4 way intersections on the way. When a car is driving and it approaches a light that just turned red this is called a preemption interrupt. The car driving (func Car.Drive(a, b point)) is forced to stop and the intersecting lane's traffic signal turns green and the cars waiting on this light are allowed to resume driving.

The important point to take away from this system is that the cars resume from their previous location they were at between point A and B when preempted in their Drive() methods. Which relates to our real world example because if our cars are stopped at the second intersection, they should logically resume driving at the second intersection when the signal turns green.

Communicating Sequential Processes:

This model is best represented by the set of people that exist within the current environment context. Whether they are driving cars down the street, walking to work, dining out with their significant other, it doesn't matter because we are looking at the entire system of people as processes with their own unique mind and tasks.

As far as the individual people are concerned, they might as well be the only people on the street because they are only concerned with their current task and agendas. For example lets say we have a CSP person named Bob who is currently late for work. He doesn't need to be concerned with the couple eating dinner across the street if his only priority is to get to work ASAP.

However when Bob wants to cross the street, he needs to check and make sure its safe to cross the street. If it isn't, then he needs to try and communicate his existence with the drivers that could possibly run him over by accident as he runs across the street.

This concurrent system is very organic.

Actor Model:

This system is a lot like the communicating sequential processes model except communicating messages between actors isn't synchronized communication.

The actor model is best described as an office building with multiple floors of employees (actors) who each have a message passing air tube connected to a central autonomous message sorting system. An employee can only send a message to another employee if he knows their desk number and messages may not arrive at an employee in the order they were sent out if the actor model implementation doesn't pipeline the messages. From the employee's point of view there is no way to check whether or not a message was received in a FIFO manner.

When an employee receives a message, and depending on the contents of that message; an employee may dispatch messages, hire new employees, or plan ahead the way they will handle the next message. The main difference between the Actor Model and CSP is that an actor transmits messages to a specific actor by sending to the actor's address that must be known to the sending actor. Communicating sequential processes on the other hand are anonymous and may (or rather should) only communicate with other processes by sending information directly to the processes it shares a communication channel with.

The actor model is inherently concurrent by design and is very capable of running in parallel.

Concurrency:
In Rob Pike's talk about "Concurrency is not Parallelism.", the overall point that Rob was trying to make in my opinion is that Concurrency is too often mistakenly understood and explained as if it was a synonym for parallelism. The idea that a concurrent system is a system where all processes are executing either literally in parallel or multiplexed on a single thread to simulate executing in parallel. This is not correctly describing concurrency because there are examples of concurrency that are not trying to simulate parallelism at all.

In the preemption example I describe a concurrent system that isn't really parallel by design but rather has a "heave and hoe" kind of execution flow. However, there is a way to make this model benefit from parallelism and that's by creating another instance of cars to start from Point A and make them travel to Point B one intersection behind the previous car. We could even take in one more step further and double our potential parallelism by putting two cars at a time riding next to each other in an embarrassingly parallel way.

 This is the example that should really begin to shed light on what a concurrent system actually is for those trying to understand the difference between parallelism and concurrency. The truth is concurrency is not parallelism but every system that runs in parallel IS concurrent.

 Parallelism is a mode of execution, concurrency is a model of isolated programming contexts.