24,542 reputation
660107
bio website
location Mountain View, CA
age
visits member for 4 years, 6 months
seen 15 mins ago

Software engineer at Google. Not an enterprise developer anymore. :-)

Stuff I've used or currently use:

  • JavaScript, jQuery, etc.
  • AngularJS, Knockout, and similar MV* frameworks
  • .NET/ASP.NET/MVC/Web API
  • NServiceBus, RabbitMQ/EasyNetQ, pub/sub frameworks
  • Selenium/WebDriver, SpecFlow, various BDD tools
  • A bit of D3
  • A bit of Java
  • Delphi
  • SQL Server, SQL CE
  • NoSQL (MongoDB, RavenDB, Redis, etc.)
  • Oracle (although I try to forget)
  • Web Services (REST, SOAP, WSE, WCF)
  • Web Applications (MVC, MVVM, JS)
  • Embedded Systems (HCxx, PIC, etc.), but that's ancient history

Other things I know about:

  • SOA and Distributed Systems Design
  • Web security
  • UI Design & Data Visualization
  • Project Management (Agile & not-so-Agile)
  • Software QA and test automation
  • Doing tech talks that don't put everyone to sleep
  • etc.

7h
comment What kinds of Open-Source licenses are NOT OK to use internally in a corporation?
@hvd: It may shock you to know that corporate lawyers don't really care about things like "free" or "unfree". They care about "can we use this without getting sued?". Have you actually read the WTFPL? It tells you nothing. Read section 2 of the Apache License to see what a proper copyright clause looks like. The WTFPL neither explicitly grants a copyright license, nor does it make said license irrevocable. You don't need to read the FSF's evaluation - just look at the license yourself!
8h
comment What kinds of Open-Source licenses are NOT OK to use internally in a corporation?
@hvd: You're citing a bunch of open-source software foundations as evidence here. My whole point is that these license agreements are generally fine for open-source software, but have a lot of problems when it comes to commercial purposes, even if the software is only "internal". One of the major issues with WTFPL is that it doesn't have a "no warranties" clause. To that, the authors respond "add your own", which doesn't address the issue at all. My source is actual corporate lawyers, both full-time and consultant. I neither need nor am inclined to search for an internet source.
15h
comment What kinds of Open-Source licenses are NOT OK to use internally in a corporation?
Most companies simply won't touch "copyleft" licenses, and for good reason; it's borderline impossible to perfectly "quarantine" a system and ensure that nothing ever indirectly touches the GPL/AGPLed code. Some apparently "permissive" licenses like WTFPL are no help either, because they're too vague on important legal issues like copyright. Even if you think you could successfully defend against a lawsuit, do you really want to go through that? (Hint: Your lawyercats probably don't.) Stick to Apache and MIT. I think BSD is also OK.
16h
comment What kinds of Open-Source licenses are NOT OK to use internally in a corporation?
Just be very careful about the meaning of the word "internal". Older open-source licenses, such as the original GPL, had loopholes that permitted its use as a "back-end" library or product. You could use a GPL database product to hold the content for a commercial web site. Newer licenses, such as the AGPL, are essentially "viral" - they apply to the entire network, and if you have a user-facing/commercial product that talks to some internal product using AGPL software, even in a trivial fashion, you would technically be in violation of the license unless you release all your source code.
Mar
21
comment When is it a good idea to force garbage collection?
@Neil: There's lots of code in the .NET Framework that's intended for (a) profiling and instrumentation, (b) library development, and (c) interop with unmanaged code. Any of these scenarios could potentially involve GC.Collect, although it is very rare even in those scenarios. People aren't saying never call it, they're saying if you have to ask when you should call it, then you should never call it. That's different. It's a bit like "you'll understand when you're older". If you ever really need GC.Collect, you'll know beyond a shadow of a doubt; if you don't know, don't call it.
Mar
19
awarded  Nice Answer
Mar
17
comment why is the latter function 10% faster although it must create the variables over and over again?
@amon: That might be how you'd ideally like it to work, but it's not how it actually works. People far more knowledgeable and experienced than I have written books about this; in particular I'd point you to High Performance JavaScript by Nicholas C. Zakas. Here's a snippet, and he also did a talk with benchmarks to back it up. Of course he's certainly not the only one, just the most well-known. JavaScript has lexical scoping, so closures actually really aren't that special - essentially, everything is a closure.
Mar
15
answered why is the latter function 10% faster although it must create the variables over and over again?
Mar
1
comment When NOT to apply Dependency Inversion?
@Kevin python was hardly the first language to possess either dynamic typing or loose mocks. It's also completely irrelevant. The question is not what an object's type is but how/where that object is created. When an object creates its own dependencies, you're forced into unit-testing what should be implementation details, by doing horrible things like stubbing out constructors of classes that the public API makes no mention of. And forgetting about testing, mixing behavior and object construction simply leads to tight coupling. Duck typing doesn't solve either of those problems.
Feb
28
comment When NOT to apply Dependency Inversion?
The DIP has absolutely nothing whatsoever to do with the type system. And in what way are "first-class types" unique to python? When you want to test something in isolation, you're supposed to substitute test doubles for its dependencies. Those test doubles can be alternate implementations of an interface (in statically-typed languages) or they can be anonymous objects or alternate types that happen to have the same methods/functions on them (duck typing). In both cases, you still need a way to actually substitute an instance.
Feb
28
comment When NOT to apply Dependency Inversion?
No? I do plenty of work in JavaScript and it still applies equally well there. The "O" and "I" in SOLID can get a little blurry, though.
Feb
26
answered When NOT to apply Dependency Inversion?
Feb
26
comment When NOT to apply Dependency Inversion?
Meh, (a) I disagree that SOLID = enterprisey and (b) the whole point of SOLID is that we tend to be extremely poor forecasters of what will be needed. I have to agree with @Stephen here. YAGNI says that we should not try to anticipate future requirements that aren't clearly spelled out today. SOLID says that we should expect the design to evolve over time and apply certain simple techniques to facilitate it. They are not mutually exclusive; both are techniques for adapting to changing requirements. The real problems happen when you try to design for unclear or very distant requirements.
Feb
26
comment Is it premature optimization to add database indices?
I'd add that if you understand the query patterns of your application and have set expectations regarding the amount of data in various tables (and its uniformity or lack thereof), you should be able to set up reasonable indices before any kind of release. You might miss a few, or need to tweak a few, after profiling the production app, but that's better than releasing a database with no indices at all and relying strictly on profiling rather than analysis. Load testing can miss scenarios that common sense would catch. Also: there's generally not much of an excuse for not having a primary key.
Feb
21
answered Which way is more efficient for getting the space count?
Feb
9
comment Why is instance creation the way it is?
@Pharap: I have done exactly that, in several other questions. The simple answer is that users (authentication/identity) and security policy (authorization/permissions) should be treated as separate concerns, and the standard models for security policy are either role-based or claims-based. Inheritance is more useful to describe the object that actually does the authentication, e.g. an LDAP implementation and a SQL implementation.
Feb
8
comment Why is instance creation the way it is?
Good example of the specification; bad example of inheritance. To anyone else reading this, please, don't try to solve user roles using inheritance.
Feb
8
comment Is it necessary to write a javadoc comment for EVERY parameter in a method's signature?
@supercat: I'm just not seeing it, sorry. Unless you're writing a game or graphics software and drawing trillions of these (in which case, you really shouldn't be writing it in Java), the CPU/memory cost is not even going to be noticeable. And Polyline(new Point(0, 0), new Point(1, 1), new Point(2, 0)) is far more readable than Polyline(0, 0, 1, 1, 2, 0) despite being more verbose. The longer those parameter lists get, the harder it is to keep track of the even/odd indexes and know at a glance which is X and which is Y.
Feb
7
comment Is it necessary to write a javadoc comment for EVERY parameter in a method's signature?
@supercat: I'd argue that in such a case, you should be refactoring, such that you have a single data type, Point, and the function simply takes three Points (or better yet an array/iterable of them). The more parameters a method has, the more unwieldy it is to call and the more unstable its specification tends to become over time.
Jan
26
awarded  Revival