1,967 karma · joined December 30, 2010
Anyone else think of Foundation's "Psychohistory" when reading this article?
Also, wow, that's a lot of money. Does anyone know where money generated by lawsuits and fines goes?
As part of Compliance, the merchant attests that he never handles the cardholder information, and that closes off huge portions of it.
The most interesting item was kalvin's find about why they proxy your code (and what their value-add is over window.onerror):
http://blog.proxino.com/post/8388203148/catching-the-worlds-...
"At Proxino, there’s one question I receive with uncommon frequency: why the proxy? After all, we only ever (at the moment) handle exceptions for you, and so there is curiosity. Is it really necessary, my customer will ask. He considers, perhaps, that the proxy is some clever ploy, a small glimpse at our plans for world domination. A lovely thought, if only it were so. Developers in particular have a tendency to believe that what Proxino does can be done dynamically. They are mistaken.
In a general sense, what Proxino does is a form of global exception handling, a way to catch every exception that occurs within your Javascript. To their credit, our customers correctly suspect that some approximation of this can be achieved dynamically. For it certainly can. Here is a naive first pass attempt at such a global handler, no proxy required:
window.onerror = function(e){ console.log(e) }
Unfortunately, window.onerror does not work in every browser, nor on every piece of code. It will fail to catch some exceptions raised by elements of jQuery, and other similarly complex libraries. It’s a simple one-liner, and it sort of works. But quite often, sort of is not enough.
With a bit more care — and a lot more code — a clever programmer can find dynamic work arounds for most browsers and most popular libraries. However in the general case, a global exception handler constructed dynamically is something of an elusive, asymptotic state. You are simply not going to get there. And this brings me to my point. Proxino is not interested in most. We want to catch, and tell you about, everything that goes wrong in your Javascript. Enter the proxy.
When a request reaches proxy.proxino.com, we lookup your existing code, parse it into AST form, and walk down the tree inserting special try/catch blocks within each function definition, as well as around the file itself. We then serve this instrumented file to your users, and handle every exception that occurs. Naturally, we have optimized this process for speed (with caching, etc.) but this guarantees us — and more importantly, you — complete code coverage. You will know about every exception.
Dynamic approaches are incredibly convenient in some ways, but in the general case they simply don’t work. And so there is a Good reason for the proxy. Hope this helps."
Both are Apps, and both allow you to write code against them (or maybe Twitter doesn't count because it doesn't run on their site?)
I think the usual complaint is that people use operator overloading for non-mathematical operations. For example, a guy doing a webapp might overload the "+" operator for Group and User as a clever way to add a User to a Group. This turns out to be a terrible idea.
In fact, my eyes glaze over as I read Scala code for this very reason, because everyone and their mother defines a method with some random array of symbols because it makes sense to them and they prefer shorthand. It makes the code totally unreadable.
It adds half a second or more to initial page load times. For doing any sort of marketing where potential customers are arriving at your landing page, that's huge.
I think the ideal way for builds to work is to be able to define packages (that can be source, libraries, data, a genrule that runs a shell command) and the dependencies of that package (references to other packages). The build system should just know how to build various kinds of code (or maybe have one spot for configuring how your Java build runs, for example). It should also know what output files to look for, so that it can avoid re-building files over and over again. For the common languages, it can deduce where the built file should be. For genrules, the developer can specify what the output files are.
Issues I had with ant: Ant requires you to specify the mechanics for how to build everything. It is difficult to impossible to express more complicated build rules (e.g. arbitrary shell commands were a huge pain). It also was very slow for incremental builds involving multiple projects, and it did not provide incremental builds for most build artifacts. For example, if an 'ant' rule generates a file, it will do so every time unless you write custom code to skip doing that based on hash or timestamp.
Ant is fine for one blog of code, but when you want to stop building the world, I find things get very difficult. It became painfully slow to build stuff, and difficult to write build files correctly as our system grew.
I don't have a ton of experience with other systems, but they seem to share a lot of the same problems.
One of the closest ones I saw was gyp (http://code.google.com/p/gyp/), but it didn't support Java
Even at my current ~12 developer company, we have too big and interconnected of a codebase to reasonably manage with ant, or buildr, or anything else I saw. We won't run into "we can't build our code fast enough" for a long time still :)
There is just a huge gap in build systems, for teams between ant at the small end and and google3 at the astoundingly huge end
The particular characteristic that I saw missing was package-level build files. All the open source guys really wanted you have one big build file that described how to build everything, rather than bunch of small ones that could be composed.
I agree that splitting the city state is probably more complicated than it's worth though.
I'm interested by the fact that he has sufficient Go code to compile to make distribution useful. After all, a Go screencast shows the entire standard library getting compiled in seconds on a macbook.
In Go, something implements an Interface by virtue of having the right method. No "implements" declaration is necessary. This is statically typed and safe at compile time, while Python is not.
Does anyone know what this feature/pattern is called? As far as I know, Go is the first language to have this feature. Seems different from "Duck Typing" to me..
Reference: http://golang.org/doc/go_faq.html#types
Rather than requiring the programmer to declare ahead of time that two types are related, in Go a type automatically satisfies any interface that specifies a subset of its methods. Besides reducing the bookkeeping, this approach has real advantages. Types can satisfy many interfaces at once, without the complexities of traditional multiple inheritance. Interfaces can be very lightweight—having one or even zero methods in an interface can express useful concepts. Interfaces can be added after the fact if a new idea comes along or for testing—without annotating the original types. Because there are no explicit relationships between types and interfaces, there is no type hierarchy to manage or discuss.
I tried to build something with it about 6 months ago. Every piece of sample code I found used a different combination of classes/frameworks, and it was in the middle of an ORM switch from Mapper to Record (or something). It was a disaster, and I gave it up after a couple days of frustration.
Code organization is basically up to you. The default organization is the typical MVC directories, but that's not a requirement for anything (and you can add other directories / subdirectories as you wish).
The one caveat on code organization is that Play! hot-compiles all code under its /app directory. My approach to sharing code with other non-Play! projects is to use "ant" to build a jar, and add that to the classpath of my Play! project. The end result is that you get hot-compilation of everything specific to your webapp, but you have to use ant to build code outside of that. I find it works fine in practice, and if it's a standalone app then you never have to leave hot-compile land.
Maintainability is great -- Play! makes heavy use of ThreadLocals, so you can access the current Request, Response, template arguments, etc etc no matter where you are, without having to pass it all around as method parameters. So making helper methods is super easy. We created a "helpers" package to put functionality shared across Controllers and can follow DRY without a problem.
Play! is by far the best web framework I've ever seen for Java.
It is as hot as node.js and socket.io combined! I can't really recommend it highly enough.
======
Strong points:
* A life-changingly fast edit-test loop. (Faster than Django!)
- Excellent beaning for form parameters (no longer have to mess around with Integer.parseInt(getParameter("objectId")))
- Libraries that obviate the crufty old ones, e.g. instead of Apache WebClient, just use WS.url("google.com ").get(). It has OAuth, Emailers, etc.
- Support for new technologies, e.g. WebSockets
- Support for non-blocking IO in imperative-looking code. (e.g. you can "waitFor()" a Future, which will cause Play! to suspend your request until the Future is ready, reusing your Thread for another request, and resume where you left off)
- Much better interceptor model than J2EE (can apply interceptors to your entire class, to individual methods by annotating, e.g. @Before, @After, @Finally)
- A routes file instead of web.xml
- Large selection of community modules to do everything from rendering your template as PDF to inlining CoffeeScript in your page.
- A framework for running scheduled jobs and for triggering asynchronous jobs from web requests.
======
Weak points:
- The default Groovy templates are powerful, but notoriously slow. The template system is supposed to be pluggable, but I haven't yet found a templating technology that feels perfect.
- The heavy use of reflection and bytecode manipulation is what makes things so convenient, but I can also imagine it being a turn-off for some.
- The Play! codebase is very light on comments.
======
Give it a shot if you haven't already.
- Play! Fanboi
Can't argue with that. But all of the difficult problems mentioned in the post are difficulties with any distributed system, not specific to calendar at all!
Microsoft has probably been having those same issues with Word, Excel, even Powerpoint as they have been working on making them collaborative for a long time now...
HN: What are the best technologies for writing large JS apps?
I have experience writing Closure (http://code.google.com/closure/) and its structure is pretty scalable, but it feels like so much effort to do simple things. Styling the widgets is a pain. Making a custom widget (extending goog.ui.Component) is surprisingly difficult to get right for even simple extensions.
After all that, I still think it's probably better to develop in that over jQuery -- at least you end up with a straightforward, modular, testable structure at the end of the day.
Is there something better? backbone?
If the bar for getting away from it is rewriting millions of lines of code and retraining 1/3 - 1/2 of their engineers, it seems credible to me.
The essential difference that annoys me to no end: - In Mercurial / Git, you must be synced to tip in order to push. (to avoid creating new heads) - In Perforce (and other old style VCS), you can commit as long as the files that you are committing are based on the newest version.
It is impossible to have any sort of sizeable team commit to the same DVCS repo. With ~12 software engineers, I already have to sync 25 times a day, even if I'm the only one touching my area of the codebase.
Most Google engineers commit to the same repository, and everyone gets the benefits of building from head (instant fix propagation from other systems, rather than waiting for releases). There is no way for everyone to work on the same repo with a DVCS afaik. It would require some sort of complicated hierarchy of repos.