Monday, 30 March 2015
Wednesday, 25 March 2015
Applied Philosophy, a.k.a. "Hacking"
Every system has two sets of rules: The rules as they are intended or commonly perceived, and the actual rules ("reality"). In most complex systems, the gap between these two sets of rules is huge.
Sometimes we catch a glimpse of the truth, and discover the actual rules of a system. Once the actual rules are known, it may be possible to perform "miracles" -- things which violate the perceived rules.
Hacking is most commonly associated with computers, and people who break into or otherwise subvert computer systems are often called hackers. Although this terminology is occasionally disputed, I think it is essentially correct -- these hackers are discovering the actual rules of the computer systems (e.g. buffer overflows), and using them to circumvent the intended rules of the system (typically access controls). The same is true of the hackers who break DRM or other systems of control.
Writing clever (or sometimes ugly) code is also described as hacking. In this case the hacker is violating the rules of how we expect software to be written. If there's a project that should take months to write, and someone manages to hack it out in a single evening, that's a small miracle, and a major hack. If the result is simple and beautiful because the hacker discovered a better solution, we may describe the hack as "elegant" or "brilliant". If the result is complex and hard to understand (perhaps it violates many layers of abstraction), then we will call it an "ugly hack". Ugly hacks aren't all bad though -- one of my favorite personal hacks was some messy code that demonstrated what would become AdSense (story here), and although the code was quickly discarded, it did it's job.
Hacking isn't limited to computers though. Wherever there are systems, there is the potential for hacking, and there are systems everywhere. Our entire reality is systems of systems, all the way down. This includes human relations (see The Game for an very amusing story of people hacking human attraction), health (Seth Roberts has some interesting ideas), sports (Tim Ferriss claims to have hacked the National Chinese Kickboxing championship), and finance ("too big to fail").
We're often told that there are no shortcuts to success -- that it's all a matter of hard work and doing what we're told. The hacking mindset takes there opposite approach: There are always shortcuts and loopholes. For this reason, hacking is sometimes perceived as cheating, or unfair, and it can be. Using social hacks to steal billions of dollars is wrong (see Madoff). On the other hand, automation seems like a great hack -- getting machines to do our work enabled a much higher standard of living, though as always, not everyone sees it that way (the Luddites weren't big fans).
Important new businesses are usually some kind of hack. The established businesses think they understand the system and have setup rules to guard their profits and prevent real competition. New businesses must find a gap in the rules -- something that the established powers either don't see, or don't perceive as important. That was certainly the case with Google: the existing search engines (which thought of themselves as portals) believed that search quality wasn't very important (regular people can't tell the difference), and that search wasn't very valuable anyway, since it sends people away from your site. Google's success came in large part from recognizing that others were wrong on both points.
In fact, the entire process of building a business and having other people and computers do the work for you is a big hack. Nobody ever created a billion dollars through direct physical labor -- it requires some major shortcuts to create that much wealth, and by definition those shortcuts were mostly invisible to others (though many will dispute it after the fact). Startup investing takes this hack to the next level by having other people do the work of building the business, though finding the right people and businesses is not easy.
Not everyone has the hacker mindset (society requires a variety of personalities), but wherever and whenever there were people, there was someone staring into the system, searching for the truth. Some of those people were content to simply find a truth, but others used their discoveries to hack the system, to transform the world. These are the people that created the governments, businesses, religions, and other machines that operate our society, and they necessarily did it by hacking the prior systems. (consider the challenge of establishing a successful new government or religion -- the incumbents won't give up easily)
To discover great hacks, we must always be searching for the true nature of our reality, while acknowledging that we do not currently possess the truth, and never will. Hacking is much bigger and more important than clever bits of code in a computer -- it's how we create the future.
Or at least that's how I see it. Maybe I'll change my mind later.
See also: "The Knack" (and the need to disassemble things)
Sometimes we catch a glimpse of the truth, and discover the actual rules of a system. Once the actual rules are known, it may be possible to perform "miracles" -- things which violate the perceived rules.
Hacking is most commonly associated with computers, and people who break into or otherwise subvert computer systems are often called hackers. Although this terminology is occasionally disputed, I think it is essentially correct -- these hackers are discovering the actual rules of the computer systems (e.g. buffer overflows), and using them to circumvent the intended rules of the system (typically access controls). The same is true of the hackers who break DRM or other systems of control.
Writing clever (or sometimes ugly) code is also described as hacking. In this case the hacker is violating the rules of how we expect software to be written. If there's a project that should take months to write, and someone manages to hack it out in a single evening, that's a small miracle, and a major hack. If the result is simple and beautiful because the hacker discovered a better solution, we may describe the hack as "elegant" or "brilliant". If the result is complex and hard to understand (perhaps it violates many layers of abstraction), then we will call it an "ugly hack". Ugly hacks aren't all bad though -- one of my favorite personal hacks was some messy code that demonstrated what would become AdSense (story here), and although the code was quickly discarded, it did it's job.
Hacking isn't limited to computers though. Wherever there are systems, there is the potential for hacking, and there are systems everywhere. Our entire reality is systems of systems, all the way down. This includes human relations (see The Game for an very amusing story of people hacking human attraction), health (Seth Roberts has some interesting ideas), sports (Tim Ferriss claims to have hacked the National Chinese Kickboxing championship), and finance ("too big to fail").
We're often told that there are no shortcuts to success -- that it's all a matter of hard work and doing what we're told. The hacking mindset takes there opposite approach: There are always shortcuts and loopholes. For this reason, hacking is sometimes perceived as cheating, or unfair, and it can be. Using social hacks to steal billions of dollars is wrong (see Madoff). On the other hand, automation seems like a great hack -- getting machines to do our work enabled a much higher standard of living, though as always, not everyone sees it that way (the Luddites weren't big fans).
Important new businesses are usually some kind of hack. The established businesses think they understand the system and have setup rules to guard their profits and prevent real competition. New businesses must find a gap in the rules -- something that the established powers either don't see, or don't perceive as important. That was certainly the case with Google: the existing search engines (which thought of themselves as portals) believed that search quality wasn't very important (regular people can't tell the difference), and that search wasn't very valuable anyway, since it sends people away from your site. Google's success came in large part from recognizing that others were wrong on both points.
In fact, the entire process of building a business and having other people and computers do the work for you is a big hack. Nobody ever created a billion dollars through direct physical labor -- it requires some major shortcuts to create that much wealth, and by definition those shortcuts were mostly invisible to others (though many will dispute it after the fact). Startup investing takes this hack to the next level by having other people do the work of building the business, though finding the right people and businesses is not easy.
Not everyone has the hacker mindset (society requires a variety of personalities), but wherever and whenever there were people, there was someone staring into the system, searching for the truth. Some of those people were content to simply find a truth, but others used their discoveries to hack the system, to transform the world. These are the people that created the governments, businesses, religions, and other machines that operate our society, and they necessarily did it by hacking the prior systems. (consider the challenge of establishing a successful new government or religion -- the incumbents won't give up easily)
To discover great hacks, we must always be searching for the true nature of our reality, while acknowledging that we do not currently possess the truth, and never will. Hacking is much bigger and more important than clever bits of code in a computer -- it's how we create the future.
Or at least that's how I see it. Maybe I'll change my mind later.
See also: "The Knack" (and the need to disassemble things)
Paul Buchheit
That's the vision of WebRTC.
Imagine a world where your phone, TV and computer could all communicate on a common platform. Imagine it was easy to add video chat and peer-to-peer data sharing to your web application. That's the vision of WebRTC.
http://www.html5rocks.com/en/tutorials/webrtc/basics/
http://www.html5rocks.com/en/tutorials/webrtc/basics/
Tuesday, 24 March 2015
Monday, 23 March 2015
Saturday, 21 March 2015
Wednesday, 18 March 2015
Tunnelss a proxy from HTTPS to HTTP for POW
The Magic
Tunnelss is a mix between the tunnels gem and the powssl script.
- It builds a root-level certificate (a Certificate Authority) and registers it as a trusted root certificate (you will need to do it manually for Firefox).
- It generates a SSL certificate matching the Pow
.devdomains. - It runs an EventMachine server which acts as proxy from HTTPS to HTTP (just like tunnels), using the generated certificate so that your browser will not complain your SSL connection is not valid!
Tunnelss
Installation
$ gem install tunnelss
If you're using rbenv:
$ rbenv rehash
Run
$ sudo tunnelss
Don't worry, the first time you launch it it will generate a certificate and ask for your permission to add it to trusted authorities (see The Magic above for more details).
If you are using rvm:
$ rvmsudo tunnelss
Visit https://myproject.dev :D
Tuesday, 17 March 2015
Friday, 13 March 2015
Thursday, 12 March 2015
Wednesday, 11 March 2015
Sync rails public folder aws s3 bucket rake task
https://ariejan.net/2011/01/01/rake-task-to-sync-your-assets-to-amazon-s3cloudfront/
Monday, 2 March 2015
CSE341: Programming Languages, Winter 2013
http://courses.cs.washington.edu/courses/cse341/13wi/
CSE341: Programming Languages, Winter 2013
Course Information
Course Materials
Material in the future naturally subject to change in terms of coverage or schedule
- Unit 1: ML Functions, Tuples, Lists, and More Reading Notes Videos
- L1. Jan 7-9: Course Mechanics, ML Variable Bindings slides: pptx pdf pdf6up code: sml
- L2. Jan 9: Functions, Pairs, Lists slides: pptx pdf pdf6up code: sml
- S1. Jan 10: Emacs, SML Mode, Shadowing, Error Messages slides: pdf pdf4up code: errors.sml solutions.sml
- L3. Jan 11: Local Bindings, Options, Benefits of No Mutation slides: pptx pdf pdf6up code: sml
- Unit 2: Datatypes, Pattern Matching, Tail Recursion, and More Reading Notes Videos
- L4. Jan 14: Records, Datatypes, Case Expressions slides: pptx pdf pdf6up code: sml
- L5. Jan 16: More Datatypes and Pattern Matching slides: pptx pdf pdf6up code: sml
- S2. Jan 17: Type Synonyms, Polymorphism, & More slides: pptx pdf code: synonyms.sml generics.sml equality.sml fun_patterns.sml
- L6. Jan 18: Nested Pattern-Matching, Exceptions, Tail Recursion slides: pptx pdf pdf6up code: sml
Tail recursion moved to Jan 23 after the Jan 21 holiday - Unit 3: First-Class Functions and Closures Reading Notes Videos
- L7. Jan 23: First-Class Functions slides: pptx pdf pdf6up code: sml
- S3. Jan 24: Standard-Library Docs, Unnecessary Function Wrapping, Map, & More slides: pdf pdf4up code:sec3.sml higher-order.sml
- L8. Jan 25: Lexical Scope and Function Closures slides: pptx pdf pdf6up code: sml
- L9. Jan 28: Function-Closure Idioms slides: pptx pdf pdf6up code: sml
- Unit 4: ML Modules, Type Inference, Equivalence, & More Reading Notes Videos
- L10. Jan 30: ML Modules slides: pptx pdf pdf6up code: sml
- S4. Jan 31: Mutual Recursion, More Currying, More Modules slides: pptx pdf code: all_pairs.sml bank.sml mutual_rec.sml
- L11. Feb 1: Type Inference slides: pptx pdf pdf6up code: sml
- L12. Feb 4: Equivalence slides: pptx pdf pdf6up
- Course-Motivation Interlude, Feb 4-6 slides pdf pdf6up Videos
- Unit 5: Racket, Delaying Evaluation, Memoization, Macros Reading Notes Videos
- L13. Feb 6-11: Racket Introduction slides: pptx pdf pdf6up code: rkt
- S5. Feb 7 <Midterm Review for Midterm on Feb 8>
- L14. Feb 13: Thunks, Laziness, Streams, Memoization slides: pptx pdf pdf6up code: rkt
Some of the material in L14 is covered in S6 instead - S6. Feb 14: More streams, memoization, etc. slides: pdf pdf6up code: sec6.rkt streams.rkt
- L15. Feb 15: Macros slides: pptx pdf pdf6up code: rkt
- Unit 6: Structs, Implementing Languages, Static vs. Dynamic Typing Reading Notes Videos
- L16. Feb 15-20: Datatype-Style Programming With Lists or Structs slides: pptx pdf pdf6up code: rkt sml
- L17. Feb 20-22: Implementing Languages Including Closures slides: pptx pdf pdf6up code: rkt
Some of the material in L17 is covered in S7 instead - S7. Legal ASTs, Macros as Functions, and More slides: pdf
- L18. Feb 22-25: Static vs. Dynamic Typing slides: pptx pdf pdf6up code: rkt sml
- Unit 7: Ruby, Object-Oriented Programming, Subclassing Reading Notes Videos
- L19. Feb 27: Introduction to Ruby and OOP slides: pptx pdf pdf6up code: lec19_silly.rb lec19_example.rb
- S8. Ruby arrays, hashes, ranges, blocks, and more slides (See also material posted with L20.)
Some of the material in L20 is covered in S8 instead - L20. Mar 1-4: Arrays & Such, Blocks & Procs, Inheritance & Overriding slides: pptx pdf pdf6up code: rb
- L21. Mar 4-6: Dynamic Dispatch Precisely, and Manually in Racket slides: pptx pdf pdf6up code: rb sml rkt
- Unit 8: Program Decomposition, Mixins, Subtyping, and More Reading Notes Videos
- L22. Mar 6-8: OOP vs. Functional Decomposition; Adding Operators & Variants; Double-Dispatch
slides: pptx pdf pdf6up code stage A: sml rb java code stage B: sml rb java code stage C: sml rb java - S9. Mar 7: Double-Dispatch, Expression Problem, Mixins, and Visitors slides: pdf pdf6up code: janken.rb janken.sml helpers.sml mixins.rb visitor.rb visitor.sml
- L23. Mar 8: Multiple Inheritance, Mixins, Interfaces, Abstract Methods slides: pptx pdf pdf6up code: rb
- L24. Mar 11-13: Subtyping slides: pptx pdf pdf6up
- L25. Mar 13: Subtyping for OOP; Comparing/Combining Generics and Subtyping slides: pptx pdf pdf6up
- S10. Mar 14: Review, Especially Subtyping slides: pdf counter-examples
- L26. Mar 15: Course Victory Lap slides: pptx pdf pdf6up
Cross Origin Resource Sharing (CORS) Blocked for Cloudfront in Rails
Using a CDN like AWS Cloudfront helps speed up delivery of static assets to your visitors and reduce the load on your servers. Setting up Cloudfront for your Rails apps is very simple, thanks to gems like asset_sync that work nicely with Rails’ asset pipeline compilation process and S3.
One issue can however be tricky to solve sometimes: CORS blocks.
What is happening?
If your assets are served by a CDN like Cloudfront, they can be served from a domain like
sdf73n7ssa.cloudfront.net while your app is served on www.myawesomeapp.com. This triggers CORS blocking in browsers to stop malicious websites fetching nasty resources while browsing a seemingly nice website.
The most common type of this issue is with fonts when you get something like this:
Font from origin 'https://sdf73n7ssa.cloudfront.net' has been blocked from loading by Cross-Origin Resource Sharing policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://www.myawesomeapp.com' is therefore not allowed access.
How to fix it?
When it comes to AWS Cloudfront, the most commonly suggested method is to allow CORS origins on the Cloudfront side. This method involves writing XML configuration code for AWS and uploading it on the S3 side.
There is a better and easier way!
I personally prefer using my DNS subdomains to solve this problem. If my CDN is behind
cdn.myawesomeapp.com instead of sdf73n7ssa.cloudfront.net then browsers are not going to freakout and block them as cross domain security problems.
To point your subdomain to your AWS Cloudfront domain go to AWS Cloudfront control panel, select your Cloudfront distribution and enter your CDN subdomain into the Alternate Domain Names (CNAMEs) field. Something like
cdn.myawesomeapp.com will do.
Now you can go to your DNS provider (like AWS Route 53) and create a CNAME for
cdn.myawesomeapp.com pointing to sdf73n7ssa.cloudfront.net.
You can test your new CDN domain by making sure assets served from it are coming from Cloudfront.
curl -I http://cdn.myawesomeapp.com/assets/image.png
should return something like this
HTTP/1.1 200 OK
Content-Type: image/png
Content-Length: 10414
Connection: keep-alive
Date: Mon, 22 Sep 2014 10:06:41 GMT
Last-Modified: Sun, 06 Jan 2013 16:37:19 GMT
ETag: "1c4bef3752c306b9c14a05b4a19d7d79"
Accept-Ranges: bytes
Server: AmazonS3
Age: 1599
X-Cache: Hit from cloudfront
Via: 1.1 a3c44e1caa58818cd22903047dc0faf4.cloudfront.net (CloudFront)
X-Amz-Cf-Id: sEbH-vV6deQra_YQa144RxtwhuJaWSrq-tpdiFxWdUbDbR2DnhoIrQ== Sunday, 1 March 2015
Subscribe to:
Posts (Atom)