Where the logic hides in rails apps - <AUTHOR> http://gammons.github.com/architecture/2012/12/22/where-the-logic-hides/ <comment><USER2> I'll give a proposal now: every chair of every developer shall from now on give them electric shock whenever they use the term "business logic". Ouch.

Seriously, "CreatesContact" is not really a class. It's a procedure, function with side effects, whatever you call it. Just with a class wrapper that boosts the developer ego almost as much as an AbstractFactoryManagerFactory.

No, modules are actually great. If you have billions of tiny modules all over the place, you probably (note the "probably") optimized way too early by splitting things out into them without a clear reason.

And guess what, if a new developer comes into a project and investigate stuff, they will see the model class start with all sorts of metadata, including callbacks, including those fancy ones called "before_save". If they can't guess what "before_save" means, you might want to either pay for an English class, or switch the framework to something that speaks in German.

And as for using rails as a web delivery mechanism, can you please, please, please investigate things like Sinatra and plain old rack, because those are delivery mechanisms. Rails is a framework, and it's entire point is being opinionated. If you disagree with the opinions, you probably should investigate other frameworks, or just use the libraries that you like (including those that are parts of Rails). Or maybe whack Rails into whatever shape you would like you to be in.

(Also, monolithic applications happen to the best of us, but the problems in them actually often come from the fact that they're monolithic. Stop looking for other developers to blame).

<comment><USER3> > give them electric shock

even better, force them to use COmmon Business Oriented Language

<comment><USER4> They should also use principles from the Object Management Group.

<comment><USER3> and after they finish building the system with separated business logic, suggest their business client to add a formal business requirement that all data should be persistently stored. just in case.

</comment></comment></comment></comment><comment><USER5> This is the sanest Rails design-advice that I've read in a long time.

It counters the misguided "implicit over explicit"-mantra that is both very prevalent in the rails-community and also the source of most problems.

I.e. when you watch any random RailsCast it is usually filled to the rim with obscure incantations and "look how we need only one LoC to perform $excessive_magic"!

The end-result are those deeply entangled "piles of rails" that we've all seen and suffered from. Hopelessly overloaded models and a dense mesh of hidden interdependencies that nobody grasps anymore because many of them are not even explicitly declared.

Personally I've largely given up hope on rails and am waiting for the successor. The rails-team just seems too fixated on digging their rabbit hole ever deeper, rather than re-visiting design mistakes that were made early on.

However, if you are stuck with a Rails-app for the time being (and who isn't..) I'd definitely recommend to follow a pattern like the one outlined in this post. The best way to use Rails nowadays is to steer clear from most of the entrenched practices and packages (e.g. devise and related trainwrecks) and to use it like a library rather than a framework - as much as that is possible.

This eases the migration to the rails-successor when it manifests, and helps preserve the sanity of your older self and _his_ successor.

<comment><USER6> _steer clear from most of the entrenched practices and packages (e.g. devise and related trainwrecks)_

I agree with your sentiment in general, but what do you suggest to use in place of devise? Surely you're not suggesting to write all the code for handling mail confirmation, password changes etc. yourself?

<comment><USER5> In fact for serious apps that are expected to grow I do recommend to write the auth yourself. It's not a lot of code, from the second time it's mostly copy/paste, and most importantly you'll fully understand what your code does and when, there will be no guesswork in one of the most important areas of your app.

Furthermore you usually end up heavily customizing whatever auth-code you start with anyway. The shrinkwrapped gems never cover even half of what an app eventually needs. Thus another advantage is that you won't have to reverse engineer devise or authlogic when you arrive at that point (and trust me, you _really_ don't want to look at their code and the SQL they emit).

That all said, in a recent project I've found the 'sorcery'-gem to provide a reasonable baseline for rolling your own. It's one of the first "second generation" Rails-gems that refrain from most of the magic and instead provide a set of primitives that you wire up yourself.

It still suffers from a bit of rails-smell (code-generators...), but overall the level of abstraction looks about right.

<comment><USER7> So you're one of those guys. I inherited a Rails app that used roll-your-own auth instead of Devise or similar — it added a significant amount of mental overhead, plus a bunch of additional logic for Facebook login.

Task that with another product I just launched: over 100K users, on Devise, no customization needed, and Login with Facebook took 1 additional library, 3 lines of code and 15 minutes.

I used to be the roll-your-own-everything guy, years ago. After maintaining dozens and dozens of Rails apps, I'm not anymore. I'm much happier when logic is pushed into libraries and I can ignore it until it matters.

> In fact for serious apps that are expected to grow I do recommend to write > the auth yourself.

No, no, no, just no. If you don't grow, you just wasted time you should have spent shipping real features. If you do grow, refactor in your own authentication later if you have to.

> you'll fully understand what your code does and when

You will, for sure. When you leave for another project and I'm brought into maintain $app, I won't, straight away.

> there will be no guesswork in one of the most important areas of your app.

There is no guesswork with 3rd-party libraries. `bundle open gem-name` is your friend. If you read through the code, you'll understand what it's doing, just like I'll have to read through your code if you roll-your-own library.

One of the major benefits to standardized libraries is that I only have to read the library for Devise or AuthLogic once across a dozen apps. I have to learn each customized solution 100% of the time.

> It still suffers from a bit of rails-smell (code-generators...)

I get the feeling that you work on really large apps with a lot of custom logic, and end up wishing you had complete control over everything. In such situations I'd probably end up agreeing with you 90% of the time if you suggested throwing out a 3rd-party library and rolling your own.

I just strongly disagree that you should start out that way. Your app should have a single selling point: "Schedule my tweets", "Remind me to pay bills", "keep track of my tasks", or whatever. Not "Log in with our unique authentication code."

No app ever became a million dollar company because a developer thought the most important job was to roll their own authentication scheme before they even scored a thousand users.

<comment><USER5> I think our opinions are not as far apart as it seems.

You are of course right that rolling your own auth won't be the first priority in your initial PoC. Neither is it needed for very simple apps or when you're dead-certain that you won't need more flexibility than the common gems provide.

However in my experience the latter almost never applies in a commercial app. Suddenly you need OmniAuth in addition to devise, and some form of ACLs. Then you grow an API that also needs some sort of auth-tokens. Then there's this other site you want to interface with which needs yet another bridge. Then one day you run that ad on TV and learn the hard way that those extra-lookups devise makes on every request are not free after all...

So what I'm saying is that the design of (in particular) devise and authlogic is just not a very good one to start from if you can already predict that you'll need customizations (beyond templating) in the future.

A frankensteined devise can be a lot harder to understand than a straightforward impl from scratch - but in the end it of course also boils down to who wrote it and whether he wrote it for the first time.

</comment></comment></comment></comment></comment><comment><USER8> Maybe this is naive, but what's wrong with just putting `UserMailer.welcome_email(user).deliver` in the controller, right after the user is created? In my mind, delegating an email to be sent should be a job for the controller.

IIRC, the Rails ideology says that "Models should not know about any part of the application except for their own datastore." Even though the :after_create hook is the "Rails way", doesn't this violate their own practices?

<comment><USER2> It's okay if that's the only case where the email should be sent, and other means of user creations should never, ever do that. It might be an issue if, for example, the email should be sent always, no matter how the user was created.

Edit: basically, the question is "which process involves sending the email". It might be "creating a user," or it might be "using the 'create user' form". At some point you might need a more abstract solution, of course — see things like Listeners, DHH's Concerns, AOP or whatever you like. But the thing is, if you don't delay too long, you can retrofit your codebase with it, so don't worry too much.

Unless you're coding up a nuclear plant or storm barrier or the moon-carving laser. Please don't use webappy principles to code drivers for the moon- carving laser.

<comment><USER9> We had a case at work for not doing this. We had a section of our app where users could set up their profile, for example /user/profile (scoped to them by their session). Imagine it is more than just CRUD, and has a few bits of complicated logic (in reality there are multiple controllers - it's a big profile :D).

We then wanted to add the ability for admins to edit profiles, so we created /admin/users/[id]/profile. If the logic wasn't in the model we would have to repeat it in both controllers (the views can easily be reused by having the form elements in partials).

<comment><USER2> Of course — complicated logic is a good hint that code maybe should be moved somewhere else, be it the model or some manager class. Just like you moved (or maybe had from the start) the form elements into partials. It's probably not something to obsess about too early.

The thing that bugs me the most is how both the article and some responses here go into heavy absolutes. Different domains have different needs, and what is "readable" changes between them, not just by size, but by shape as well. And yes, shape and size might change as the app lives (my current codebase being a great example), but you can't really predict everything.

</comment></comment></comment></comment><comment><USER10> These kinds of callbacks, which remind me about the "aspect oriented programming" that was hyped for a short while a few years ago, look super dangerous.

I could easily imagine someone unaware of this hook running a test to create a bunch of user entries, sending emails all over the place without even realizing.

It's like someone read <http://en.wikipedia.org/wiki/COMEFROM> and took it seriously.

<comment><USER7> Anybody who doesn't have something like mail_safe [1] installed is asking for trouble, no matter where he stores his business logic.

[1] <https://github.com/myronmarston/mail_safe>

<comment><USER10> That's a nice solution to the "emails gone wild" problem, but - no offense - it's a bit besides the point.

We could just as well be talking about S3 data, facebook posts, tweets, anything with (side) effects beyond the active database record in question.

</comment></comment></comment><comment><USER11> The author seems to contradict himself.

First he claims that sending an email after user creation is conventionally done in the model. Then in his hypothetical scenario a new dev comes in and looks at the controller to discern that same logic.

He completely misses the point, if its conventional to put the welcome email logic in the model then we can expect the new dev to look for the logic in the model.

The whole point of rails is convention above all.

</comment><comment><USER12> While I don't like the name of the service object "CreatesContact", I disagree with the statement that the sending of an email should reside within the create_contact! method. The author's intent is to shield any new developers from methods that say one thing and do another, yet he adds email delivery into the create_contact! method without informing the developer what may happen (unless some magic flag is set somewhere).

A simpler, more contrived example, would be to create a new function create_and_send_email! and place the creation logic and email sending logic in there. And now, when the developer uses the service object, she has the ability to choose between just creating the contact, or creating it and sending an email.

        class CreatesContact
          def initialize(contact)
            @contact = contact
          end

          def create_contact!
            @contact.save
          end

          def create_contact_and_send_email!
            create_contact!
            deliver_contact_created_email
          end
        end

<comment><USER13> In the Obvious architecture, it would be something more like..

        class CreateContact
          def initialize contact_jack, email_jack
            @contact_jack = contact_jack
            @email_jack = email_jack
          end

          def do input
            # validate input

            contact = Contact.new
            contact.populate input

            contact_jack.save contact.to_hash

            email = ContactEmail.new
            email.populate contact.to_hash

            email_jack.send email.to_hash

            contact.to_hash
          end
        end

With that structure you can call CreateContact with:

        action = CreateContact.new
        result = action.do ContactJack.new, EmailJack.new

In that structure you can totally test the action and logic without hitting the db or the mail system at all. Your ContactJack and EmailJack can be easily swapped out for various pluggable data stores. Fileystem, MySQL, Mongo, Postgres, Cassandra, could be swapped out for the ContactJack. EmailJack could send through standard mail servers, SendGrid, Amazon AWS, Mandrill, etc.

Obvious is on github, you can read more at <http://obvious.retromocha.com>

</comment></comment><comment> daniel-levin I like the idea of one-class-one-responsibility but have a number of questions:

1) Isn't the whole idea of ActiveRecord that persistence is hidden from the model programmer? Surely the model doesn't actually have 'triple duty' because it doesn't contain any persistence code?

"Imagine you are a brand new developer on the team that supports this app. You see the @contact.save call but now, the fact that it performs business logic is even harder to see, since the logic is placed in another module, somewhere in some other directory." - I will imagine I am a new developer on the project:

2) My expectations have been subverted. My understanding of Rails conventions is that business logic _does_ live inside the model which _will_ be inside app/models. Therefore, the first question I'd ask myself would be: "What business logic happens when this an instance of this model is created?" Surely Rails supports this paradigm by virtue of the existence of after_create? Wouldn't I have to visit a __third __class in non-obvious location to understand the updated example(app/use_cases)?

3) Doesn't CreatesContact now have two responsibilities as well? Namely Creation and validation? And the name doesn't communicate that it performs validation as well, does it?

4) Doesn't creating this new class exacerbate the problem of code/logic being 'scattered all over the place'?

5.1) Doesn't the issue of: "[In the controller], To an outside observer, it is not entirely clear that an email will be sent." remain just as problematic as the model containing the code for sending the email? Because you'd have to mentally context switch (the single biggest obstacle to understanding code IMHO) from the controller to the CreatesContact class to see what is happening. when CreatesContact.new(@contact).create_contact! is called.

5.2) Continuing the thread of the last question, CreatesContact.new(@contact).create_contact! certainly doesn't say to the programmer: "I send an email if a certain flag was checked". Isn't this unintentionally self-defeating? The aim is a reduction of 'obfuscation', but isn't hiding what a 'single-responsibility' class _actually_ does obfuscation itself?

I don't mean to be dismissive, but, broadly, I disagree with the way you have tried to compartmentalise this application. The purpose of my questions is to help me understand your opinion.

<comment><USER13> Hey, I'm not the OP, but I have some thoughts based on my experience creating the Obvious Architecture.

1) Hiding persistance from the programmer by tying it to your models is a bad idea. It's where a lot of problems start. First, how do you test without hitting the database? How long do your tests take? Minutes? Hours? Or do you skip them?

I don't think your models should do persistance at all. They should model your data for you. Do validation against your business rules. That sort of thing.

Would you tie your models to the filesystem? If not, then why would you tie them to the database?

Pulling your persistance mechanism out of your models is the first step to writing fast, maintainable, highly testable code, even if you are still using rails.

2) Rails conventions want you to tie your DB to your objects, which is a bad idea. Rails does a lot of things well, like it gives you a nice structure for controllers, views, routing, asset management, so use it for those things. Rails is a delivery mechanism. Use it as one and leave data modeling and persistance to something else.

3) I think the name issue could be solved by treating it as "action" object. Think of actions as more like actors. They do things. They integrate models/entities and persistance mechanisms along with minor amounts of logic that don't fit inside of entities.

As an action object, you could all it CreateContact and it would be called create_contact.rb in the app/actions folder. Then, when you look in the app/actions folder, the file name communicates what it does - it creates a contact.

4) Actually, it helps a lot with testing. Creating a new class makes dependency injection super easy, making testing super easy and fast. Also, it can help with clarity and glance factor. Imagine you have an app/actions folder with files like create_contact.rb, remove_contact.rb, send_email.rb, get_contact.rb, compose_email.rb and so on. You look at that folder and you can see that it is probably an contact management and email app. Maybe an contact or newsletter management app?

That kind of glance factor you can't get with a bunch of higher level controller or service containers. It also avoids the problem of "what controller/module/service does this method belong to?"

5) I actually agree that the code that the OP did was not the best in that the persistence and email sending mechanisms aren't passed in to the action, so that you don't know what it is going to try and save and where. If the code explicitly passed in the persistence and email mechanisms it would be more apparent that an email is going to be sent as part of the CreateContact action. That being said, I would probably make those two separate actions for clarity's sake.

I've written some apps using the Obvious Architecture and it really does help solve a lot of the problems that default Rails MVC creates.

</comment></comment><comment><USER13> Ok, I've been working on an architecture pattern that is very similar to this idea and it's basically inspired by Uncle Bob's Clean Architecture and Screaming Architecture posts. I call it the Obvious Architecture.

What the OP writes about is a good first step and frankly, is very close to right, but why stop there? Why not ditch ActiveRecord models all together and totally decouple persistance from the "app"? Honestly, the coupling of your models and logic to a database is really where most of this trouble starts.

In the Obvious architecture the app is separate from the delivery mechanism (rails/sinatra/whatever) and also from the external persistance mechanisms like databases, queues, caching, and so on. You can mix and match both delivery mechanism and persistance methods. So, you could write a CLI app against the filesystem and then make a rails web app with a mysql persistance mechanism without changing your "app" at all.

The whole thing is built from day one to be TDD and in a recent app I wrote, it has some 78 rspec tests that run in 0.03 seconds.

I'm in the process of documenting and open sourcing the whole thing. There is a project generator gem available now called 'obvious' and you can read more at <http://obvious.retromocha.com/>

When I have better documentation and examples available, I plan on posting to HN, but all questions are welcome.

</comment><comment><USER14> Rails's conventions are great, and that is what makes it rails. Move on...

</comment><comment><USER15> If you have a use case that doesn't fit into your basic CRUD why not just create a new REST resource for it? For instance in my current app we have an InstallsController. This creates a new installation of the plugin, updates the user's account and send out an email. I've always steered clear of model callbacks as they don't play well with FactoryGirl/Machinist etc. As such the controller's create action describes everything that happens when our plugin is installed(it's still only 4 lines long).

This strategy of using new REST resources combined with modules for models where appropriate seems a very comfortable way to structure a large application. It fits into the rails conventions well and doesn't require new developers to do anything they're not familiar with. The other nice advantage is that your routes configuration gives a great overview of everything that can happen in your app.

</comment><comment><USER16> No, really, just use modules - they are testable and reusable and any truly professional Rails dev is going to have zero problems understanding and working with them. This smells of someone very new to Ruby/Rails.

</comment><comment><USER17> Learn your tools. New developers will need to do the same. There's zero substitute for experience. Rails solves the most common problems easily.

It's extremely common to do things upon saving. Once you need to do more than one thing upon saving you then move to a more "event" based approach.

Rails was mystifying when I first picked it up, and parts of it are mystifying today. But something as trivial as the callback chain will be second nature after some time and several apps later.

</comment><comment><USER18> We have been moving the complex logic out of the models into libraries. But we are not happy with this approach.

We also find it difficult to cleanly develop views where data is needed from several different models. The whole Rails REST and MVC model gets in the way.

Would love to hear about how other wiser people have deal with these situations.

<comment><USER19> I think what you are in need is nothing to do with model separation. But, you need to be careful about which code belongs to your business logic. For the views you mentioned, I don't know your code but I think you may use something interim, like a presenter code which takes data from the models and helps views to show it.

<comment><USER10> > something interim, like a presenter code which takes data from the models > and helps views to show it

..something like a "controller"? :P

</comment></comment></comment><comment><USER20> Anyone intersted in this style of programming needs to read "Clean Ruby" by Jim Gay. (Currently being written with beta access)

To be honest; it looks like this post might have been inspired by that book (or the concepts behind it) but I think the book does a better job explaining it (Obviously, a book vs a single blog post.)

<comment><AUTHOR> I just tore through that book just a few days ago! Definitely a lot of eye- opening things happening in relation to rails and architecture.

I think a lot of people/projects/companies have been burned attempting to upgrade rails, or have a slow test suite, or having a terrible time trying to figure out where to fit core application logic into the rails stack.

And then you have an epiphany and say, wait, rails should not define my app. You say, I should be able to upgrade to rails 4 on day 1. Rails does not define my application, my application defines my application! So if you do just a wee bit of partitioning, it goes a very long way. (much to the chagrin of DHH, who for some reason evangelizes having your core logic in ActiveRecord models, to a fault)

</comment></comment><comment><USER21> Disappointed not to see some comments from Django/Python folks here.

Or node, mvc.net, Cake, CodeIgnitor etc etc.

Is every language/framework community doomed to repeat these debates in isolation ad infinitum?

<comment><USER22> I commented in here a couple times and I do ASP.NET MVC development in C#. It just seemed like the concepts are so similar that whether you write it in C# or Ruby doesn't particularly matter.

</comment></comment><comment><USER23> Avdi Grimm has a "book" on separating business logic from Rails - <http://objectsonrails.com/>

<comment><USER19> Yes, I bought the book earlier, although it contains some valuable things but it needs an editorial review. It shows kind of things wich not simple, just complex (I said simple, not easy).

</comment></comment><comment><USER24> from Spaghetti code to Ravioli code</comment>


What are the main ways in which the world will likely be different in 20 years? - <AUTHOR> https://www.quora.com/What-are-the-biggest-ways-in-which-the-world-20-years-from-now-will-probably-be-different-from-today-What-are-the-biggest-X-factors-changes-that-are-not-probable-but-are-possible-and-could-be-huge?share=1 <comment><USER2> "What are the biggest ways in which the world 20 years from now will probably be different from today? What are the biggest "X factors" (changes that are not probable, but are possible and could be huge)?"

Come on Quora make up your mind: probable or not probable??? As of possible...mmm anything is possible!</comment>


Ask HN: What app do you use to store highlighted web pages or research papers? - <AUTHOR> I am thinking of making a Chrome extension which can store highlighted web pages (with images, CSS everything) to the cloud.<p>I want to do lots of highlighting on web pages so that I can quickly recap of previous stored content? Is such an extension worthwhile? Does something like this already exist? <comment><USER2> This doesn't apply to web pages, but Mendeley is _excellent_ for research papers [1]. It let's you easily build up a collection of papers, store highlights/notes, and export Latex bibliographies. I couldn't recommend it more.

[1] - [https://www.mendeley.com/](https://www.mendeley.com/)

<comment><AUTHOR> Thanks :)</comment></comment>


The algebraic structure of functions, illustrated using React components - <AUTHOR> https://jrsinclair.com/articles/2020/algebraic-structure-of-functions-illustrated-with-react-components/ <comment><USER2> Neat, but I think it would have even more interesting to use church encoding for your numbers. It would have shown some of the wonderful inhabitants this seemingly simple structure can lead to :)

It really is a small universe.

<comment><USER3> not related to the article itself, but Church (or Scott) encoding is, to me, one of the most eye-opening FP concepts – in order to describe a data type, you just write the way it can be pattern-matched on. and that's essentially describing how the value can "drive" your program's control flow, because you give it one or more continuations to call with some arguments.

a church¹ encoding of booleans:

      false = λ f t -> f ()
      true  = λ f t -> t ()

just says that, given a boolean value, you can choose one of two control flow paths, i.e. do

      case myBool of
        False -> "a"
        True  -> "b"

or using the church-encoded version:

       myBoolEnc
         (λ () -> "a")
         (λ () -> "b")

a product type just means "you can do stuff using the parts", i.e.

      threeAndFive = λ k -> k 3 5
      trueAndFoo   = λ k -> k true "foo"

and that just means you can do e.g.

      case myPair of
        (a, b) -> a+b

or, using the church encoded version

      myPairEnc
        (λ a b -> a+b)

it's like the ultimate "inversion of control" \- the values are driving the program by calling the continuations passed to them! tbh i always get chills when i think about this, bc it just seems like such a deep thing... lambdas really are the ultimate everything, especially values :)

(and now, a handwavy, possibly rambling conclusion)

to me, this embodies the fact that booleans, numbers and other values _have no inherent meaning_ \- what matters about them is that we can, via pattern matching or something else, distinguish e.g. True and False, or 0 and 13 and 725, and do different things. like, the bits we use to represent binary numbers have no meaning either; what matters about a particular pattern of bits is how it changes the execution of a program relative to other patterns of bits that could be in its place.

\---

¹ with some added () to work in non-lazy languages and to highlight that the type `Bool` is just the sum `Unit + Unit`

<comment><USER2> Yes, it is really cool space to explore and you can keep finding interesting gems :)

>with some added () to work in non-lazy languages and to highlight that the type `Bool` is just the sum `Unit + Unit`

Nice. But it makes sense, also semantically. Booleans are about choice and the types of the sum don't carry information, so they can be unit. While left and right mean false and true.

You should also look into FoldMap lists, which are lists encode as foldMap. That was for me magic. ([https://hackage.haskell.org/package/fmlist-0.9.3/docs/Data-F...](https://hackage.haskell.org/package/fmlist-0.9.3/docs/Data- FMList.html))

Also you might enjoy this article: [https://www.nlda- tw.nl/janmartin/papers/jmjansenLambdapaper....](https://www.nlda- tw.nl/janmartin/papers/jmjansenLambdapaper.pdf)

</comment></comment></comment><comment><USER4> Why is all the code in a hard to read font?

</comment><comment><USER5> I was expecting to see something about the algebraic laws for functors and monads.

</comment><comment><USER6> Wonderful stuff! Thanks for an awesome post.

</comment><comment><USER7> Bit off topic

Ooooh, I like the look of that site.

</comment><comment><USER8> Loved this article!</comment>


Web 2024: Waiting for the singularity - <AUTHOR> http://berjon.com/web-2024/

<comment><USER2> You couldn't resist taking a stab at PHP could you?</comment>


Git repository of New Zealand legislation - <AUTHOR> https://github.com/Br3nda/legislation/tree/master/act/public

<comment><USER2> This is interesting, but really needs to be taken a bit further. For example, the commit [https://github.com/Br3nda/legislation/commit/ed9e389c5573c98...](https://github.com/Br3nda/legislation/commit/ed9e389c5573c98ce8e3b7a3a07c614469303da4) adds the _Animal Welfare Treatment of Animals Amendment Bill_ \- but the effect of this Bill is actually to amend the _Animal Welfare Act 1999_. In other words, this Bill is a legal patch, so it should probably be shown as a git branch that contains a commit modifying the _Animal Welfare Act 1999_ as well as adding the Amendment bill.

As a sidebar, it's interesting that the _Statute of Marlborough (1267)_ is still in force in NZ.

<comment><USER3> I completely agree. I'd love for somebody to maintain a repository that follows in parallel the real life of a bill. Introducing it to Parliament is like creating a branch, then debating and process can further amend the branch/bill, then passing the bill and submitting it for royal assent is like submitting a pull request.

I'm sick of 3-page bills whose entire purpose is to remove a word or two from existing legislation. A diff is a much more powerful tool of examining the impact of a bill.

Edit: "Aaron's Law" is a good example:

> —Section 1030(e)(6) of title 18, United States Code, is amended by striking > "alter;" and inserting the following: "alter, but does not include access in > violation of an agreement..."

Tell me a diff doesn't say that better.

</comment></comment><comment><USER4> Legislation has some similarities to source commits, in that many Acts amend other Acts. Something like: _section 3: amend section 4(i) of the so-and-so Act 1958, replacing each occurrence of word A with word B._

It would be nice to store that _as_ git commits, and have the functionality of diff, blame etc.

However, the dependence on the existing format, in terms of case-law, legislation, techniques for handling it, textbooks, articles, not to mention the decades of experience of solicitors, barristers, judges and legislators, make this hard to change. Back-compatibility is important. So the way to do it is to include the present format as meta-information.

</comment><comment><USER5> While cool, note that this seems to be both incomplete and not up to date. The full list can be viewed with a search like [http://www.legislation.govt.nz/all/results.aspx?search=ta_al...](http://www.legislation.govt.nz/all/results.aspx?search=ta_all%40act%40regulation_) and the results are easily spidered - I did it a few years ago and ended up with ~5000 files totalling ~375MB.

</comment><comment><USER6> There's so many pull requests I'd like to submit...

</comment><comment><USER7> I keep wondering why all legislation isn't done in a git-like format. It really seems to be the best platform for being able to attribute and track changes on complex text documents with a large body of contributors.

</comment><comment><USER8> Now this is cool. If only we could fork it in real life.

<comment><USER9> The problem is not forking and making changes (although you will have trouble using your local version), the problem is making a pull request and having it accepted.

</comment></comment><comment><USER10> Since we are already talking about legislation, how good/bad of a climate does New Zealand's law present for entrepreneurs? Asking because I have been fascinated with the country ever since (and also with it being almost the opposite part of earth when you're from Germany it's the farthest you can possibly get away from home for a change ;-).

So, any Kiwis around to give some insights?

<comment><USER5> I'm a kiwi but can't speak from direct experience. However, there are a few articles around like this one (I read another one the other day but can't find it now): [http://www.forbes.com/sites/kurtbadenhausen/2012/11/14/new-z...](http://www.forbes.com/sites/kurtbadenhausen/2012/11/14/new- zealand-tops-list-of-the-best-countries-for-business/)

</comment></comment><comment><USER11> There exists something similar for the German law:

<https://github.com/bundestag/gesetze>

Fully converted to markdown and the best:

      You are encouraged to open pull request.
      Of course only valid legislation voted on by the
      Bundestag will be merged.

</comment><comment><USER12> First off, why is this interesting? At least, I find it pretty uninspiring.

Second, how are the dates set to 23 years ago, etc?

<comment><USER13> You can make a git commit with a date in the past (e.g. <http://ao2.it/en/blog/2009/10/30/git-commit-date-past>)

</comment></comment><comment><USER14> Now we know who to 'blame'

</comment><comment><USER15> Can someone shed some light on the xml format being used here? Is there a standard parser, or something that would make it more human-readable? I'd love it all to be Marked-down.

<comment><USER16> The XML format is that used internally by the Parliamentary Counsel Office, and is documented here: [http://www.pco.parliament.govt.nz/assets/Uploads/lenz-8-dtd-...](http://www.pco.parliament.govt.nz/assets/Uploads/lenz-8-dtd- set.zip)

</comment></comment><comment><USER17> No tests?

</comment><comment><USER18> This legislation is poorly written. Plus, we already have US legislation. This seems redundant. Reading it made my eyes bleed.</comment>


Scientists Turn Normal Red Bricks into Electricity-Storing Supercapacitors - <AUTHOR> https://www.vice.com/en_us/article/9358ye/scientists-turn-normal-red-bricks-into-electricity-storing-supercapacitors <comment><USER2> >""We discovered that if you actually treat rust chemically, it actually becomes reactive," D'Arcy explained. "So something that we typically think of as waste turns out to be a useful chemical for producing materials that can be used for storing energy."

The pigment in red bricks is partially derived from rust, which inspired the researchers to take a closer look at the structural properties of bricks to see if they could be converted to an energy-storing device called a supercapacitor.

The intricate porous interiors of bricks turned out to be an ideal space to introduce sophisticated polymer coatings, which react with rust to increase the surface area and conductivity of bricks.

As a result of the modifications, the team was able to engineer a prototype smart brick that stored enough energy to power the green light. The team is currently building on its findings by manufacturing specialized bricks with various metal oxides and polymer coatings."

My thoughts:

Character A: "It's a _brick_!"

Character B: "No, it's a _supercapacitor_!"

Character A: "Brick!"

Character B: "Supercapacitor!"

Character C: "Hey, _you 're both right_!"</comment>


Holocene Era Now Divided into Greenlandian, Northgrippian, Meghalayan by IUGS - <AUTHOR> http://www.stratigraphy.org/index.php/ics-news-and-meetings/119-collapse-of-civilizations-worldwide-defines-youngest-unit-of-the-geologic-time-scale <comment><USER2> They've named the ages of the Holocene after critical climatic events 4.2k, 8.3k, and 11.7k years ago. In other words 4.2k, 4.1k and 3.4k years apart. Looking at that series it's easy to wonder if we're overdue for another one.

I suppose it still counts if it's self inflicted.

<comment><AUTHOR> Yeah, from what I can tell from chatter online, the anthropocene has been reported on and is assumed to be true, but has not been given an official designation yet.

</comment></comment><comment><AUTHOR> The latest version of the International Chronostratigraphic Chart/Geologic Time Scale: [http://www.stratigraphy.org/ICSchart/ChronostratChart2018-07...](http://www.stratigraphy.org/ICSchart/ChronostratChart2018-07.pdf)</comment>


Drive: The surprising truth about what motivates us - <AUTHOR> http://www.youtube.com/watch?v=u6XAPnuFjJc

<comment><USER2> The "Back to the Future" bit at 7:05 or so was very funny.

I was kind of skeptical to watch a video with content I had already seen as a TED talk and nearly clicked back before it started. Once it started, I was immediately engaged, and reading parts of the talk satisfied a certain part of my brain.

<comment><USER3> Yeah-- I was just thinking that if every lecture in school was this way, how could I not stay engaged and absorb it?

<comment><USER4> Because if every lecture was that way, then that style would be the _norm_ , and therefore almost by definition you probably wouldn't be engaged, just as you aren't engaged to the norm now, and seek out unique and interesting— _novel_ things.

<comment><USER5> Sal Khan gave an interesting hypothesis about why his lectures were more engaging (he uses a blackboard) than a traditional one with a person in the front. I recommend watching the video, but his point is that we tend to focus on the person, the movement of the hands. When you remove the person, you're sort of left with a voice inside your head explaining stuff.

<http://vimeo.com/11731351>

<comment><USER6> Every reason he described there is pertinent to this video. Thanks so much for posting this, I don't know why I skipped it when it made its rounds the other day.

</comment></comment></comment></comment></comment><comment><AUTHOR> Perhaps the reason most economic approaches fail to predict this kind of behaviour is because they forget that money by itself is _not_ a motivator—it's only ever a means to an end for all who use it.

Money gives you the freedom to make choices and spend time doing other things—the autonomy and mastery that Dan Pink was talking about. However, earning more money but being stuck in the same job renders this increase in salary effectively useless, because you don't stand to gain any satisfaction simply by _having_ the money.

<comment><AUTHOR> It's worth mentioning that the underlying concept is Marginal Utility: <http://en.wikipedia.org/wiki/Marginal_utility>

</comment></comment><comment><USER7> I'm pretty sure I disagree with the moral. Does anyone really contribute to Wikipedia for the sense of mastery it gives them? Do you think the NSA releases their Linux kernel patches to increase the agency's autonomy? Do you think that most open source and free culture advocates are altruists motivated by a drive to give their stuff away to other people? No, they do it because it improves the world they live in - _for them_. Enlightened self-interest is still self-interest.

Also, the dissing on economists just rubs me the wrong way.

<comment><USER8> Quite so. It's sometimes easy to forget that making the world a better place can still be a very selfish act. Consider the man living in a world he hates, with all the money in the world, vs. a man living in a world he enjoys, with comparatively less individual wealth. In a very real sense the 2nd man is better off. A lot of this has become baked into the cultural DNA of the west. Cooperation pays dividends. Today's J. Average Middle-class Everyman living in the 1st world is much, much better off than very nearly every king, despot, prince, and emperor throughout history.

<comment> loup-vaillant > making the world a better place can still be a very selfish act

You sound like such selfness is actually concious. I don't think so. We're not Machiavellian machines, gauging the consequences of each of our deeds. For example, I bet most Wikipedia contributors don't especially want to help building the world's most comprehensive encyclopaedia, but just want to share a bit of their knowledge, or just don't like to see spelling errors.

</comment></comment></comment><comment><USER9> This is one of the best books I've read. As an entrepreneur, it will get you to think differently on how you motivate people. Before, I use to think that if I pay a person to do a task that should be sufficient. Now, I encourage purpose and deliver a vision. You would be amazed at how easy it is to 'rally the troops' by doing this.

Read this book now.

<comment><USER10> Strongly agree. The book is a quick read and has broad implications. I worked with the author (Daniel Pink) to create a mobile app based on the book. Daniel is a great guy who lives what he writes.

Plug: the app is free and called "Dan the Motivation Roo" currently on Android only

</comment></comment><comment><USER11> Aww, man. I wanted it to pan out and show the whole mural at the end.

<comment><USER12> Hmm, well, someone could make one by taking screenshots at the appropriate times and then stitching them together.

</comment></comment><comment><USER13> Beautiful presentation of a presentation! If you are like me and usually just scan the comments of HN, don't miss this one!

</comment><comment><USER14> The lecture sounded really familiar - from here: [http://www.ted.com/talks/lang/eng/dan_pink_on_motivation.htm...](http://www.ted.com/talks/lang/eng/dan_pink_on_motivation.html)

<comment><USER15> I thought I had seen this before. I remembered some candle/tacks/box task. I believe it was this TED video.

</comment></comment><comment><USER16> What a great way to watch a lecture

</comment><comment><USER17> Does anybody have any idea which software was used to create the RSA animated series?

<comment><USER18> It seems plausible that it was done by hand and then sped up to match the speed of the talk.

</comment></comment><comment><USER19> Somewhat related video from Paul Solman at PBS Newshour, on motivation and money: <http://www.youtube.com/watch?v=OGyhaZnPtC4>

(An interview with Dan Pink, author of _A Whole New Mind: Why Right-Brainers Will Rule the Future_ )

</comment><comment><USER20> I wish they had ended it with a shot of the whole board at once - Or maybe even just zoomed slowly out...

</comment><comment><USER21> Dan Ariely's book, Predictably Irrational, presents research that speaks to this issue from another angle: that we perform better at tasks framed in social norms (help a friend) vs tasks (even the same task!) done simply for money.

</comment><comment><USER22> Money is overrated. Time is undervalued. However, not everyone wants to make a contribution. And high incentives can improve the perfomance of people who wants a collateral reward of money like social status.

<comment><USER23> "And high incentives can improve the perfomance of people who wants a collateral reward of money like social status."

Do you have any science to back that up?

</comment></comment><comment><USER24> great video, almost makes one stressed looking to see if that hand will keep up with the talk though...

</comment><comment><USER25> If what he says is true, then that means Diaspora will fail, because of the huge amount of funding they got.

<comment> loup-vaillant No, for a simple reason: they _already_ got the money. If this money would be delivered only upon some milestone of the project, I would have agreed.

The fact is, once the funding round is finished, once they actually start to work, they will receive naught. On the contrary, money had been put out of the equation, at least for a time. And their very first motivation wasn't money. It was Eben Moglen's talk[1]. Pure idealism.

Four geeks in their proverbial garage set out do destroy an evil corporation is _exactly_ the right kind of incentive. They have independence, they probably seek mastery, and they have a purpose. Sure, they could become greedy and just want to get rich like an americally dreamt start-up founder, but I think this is unlikely.

Failure will come from another factors, if at all.

[1]: [http://www.softwarefreedom.org/news/2010/feb/01/freedom- clou...](http://www.softwarefreedom.org/news/2010/feb/01/freedom-cloud- software-freedom-privacy-and-securit/)

<comment><USER26> > _And their very first motivation wasn't money. It was Eben Moglen's talk[1]. > Pure idealism._

If you believe in pure idealism, then you must also believe in Santa Claus.

> _Four geeks in their proverbial garage set out do destroy an evil > corporation is exactly the right kind of incentive_

Even in the open-source world, people don't brag about their pet projects until they've got at least a preliminary design to show.

I like developers that deliver ... like Linus, when he was criticized for Bitkeeper, he came out of nowhere with Git.

<comment> loup-vaillant You will note that you didn't contradict me at all. Let me repeat: the Diaspora founders have independence (the proverbial garage and the financial relief). They also probably seek mastery (they are techno-geeks). Finally, they have a purpose (destroying the busness model of Facebook, as advocated by Eben Moglen).

Now, on to your points:

> Even in the open-source world, people don't brag about their pet projects > until they've got at least a preliminary design to show. I like developers > that deliver

I actually agree with that. This is of course a major point against Diaspora. That said, I doubt they expected such a buzz. Don't forget my primary point: their incentives increases the odds of success. I didn't talk about the _initial_ odds.

> If you believe in pure idealism, then you must also believe in Santa Claus.

I'm not sure I get your meaning. I just said that their primary motivation was a purely idealistic one. As told in the submitted video, idealism is one of the most efficient incentives. The thing is, he called that "purpose", which cleverly avoids the negative connotation of "idealism".

The negative connotation of "idealism" worries me, because we need idealism. For instance, you surely know that exponential growth, continued exploitation of the south, systematic destruction of the soil just can't go one forever. They will stop, one way or another. To put it bluntly, our civilization as we know it won't last.

Now, I see two ways our civilization could change:

(1) We continue to prefer short term maximization over long term planning. We rush to deplete the remaining resources. We continue to over-exploit and destroy our soil. A major biologic crisis ensues (that one has already started, by the way). Humanity starves and go back to a pre-feudal state, or falls prey to an oligarchy and eat Soylent Green.

(2) We think long term. We cooperate. We use the remaining oil to bootstrap renewable energies. We take care of our soil. The biologic crisis is mitigated. Humanity mostly lives in the countryside, and eats organic crops.

I'm probably wrong about the details, but the main point remain: our civilization will eventually change drastically. We could make the transition smooth and painless, or we can let it be sudden and nasty. Our choice.</comment></comment></comment></comment>


Intel Ghost Canyon NUC9i9QNX Review: NUC 9 Extreme Realizes the SFF Dream - <AUTHOR> https://www.anandtech.com/show/15720/intel-ghost-canyon-nuc9i9qnx-review <comment><USER2> SFF Dream is 'laptopification' of desktop computing. Overpriced screenless closed system laptops. No more incremental upgrades, instead inadequate cooling, power throttling, dongles and converters galore, vendor/ecosystem lockin. $2800 for last generation CPU, 16GB of RAM, and an RTX 2070.

Reminds me of [https://boingboing.net/2012/01/10/lockdown.html](https://boingboing.net/2012/01/10/lockdown.html)

<comment><USER3> This NUC has upgradable RAM, Disk, GPU, and CPU backplane.

It's a 8core 2.6GHz 45W CPU, not last generation, with lots of ports.

If you don't want a small cool powerful machine, it's not for you

</comment></comment><comment><USER4> Pricing on this is ridiculous. Build your own SFF system using MiniITX and save the money.

<comment><USER3> What if I don't want to build my own?

<comment><USER4> Actually, you know, I'm going to pull back on my original post a bit. I didn't realize they were using a $500+ Optane drive in here and not in some of the other systems they compared to... that does inflate the price quite a bit.

Still, it seems even the barebones being $1500 is a lot. Not sure where the majority of the cost is coming from otherwise without the Optane and GPU. Still seems like a decent premium, but not as exorbitant as I originally thought. Especially since there are some trade-offs (like the x8 PCI-e, etc).

If you don't feel like building one and money is not a concern- then this machine is likely perfect for you. No problem with that at all. In fact, if this machine was more affordable barebones, I'd be interested myself.</comment></comment></comment>


Ask HN: Interview as a Service – Any interest? - <AUTHOR> Hello Everyone,
TL;DR
I am offering interview as a service (taking first round on your behalf) for technical roles (0-8 yrs exp) for $150 each. Would you be interested?
Generally (assumption) even after the resume has been filtered by HR folks (who are mostly non-tech), you end up with 1 out of 5 candidate cleared after the telephonic rounds. This is definitely time consuming as developers are getting involved here and their hours are getting wasted.
If you do the calculation (assumption here), so to hire 1 candidate, you end up wasting 15-20 hours (at least) of developers time on unsuccessful interviews.
My proposal:
I will study your company, team and requirements beforehand.
Once you have identified a candidate, you can let me know and I will conduct the first round and give you a feedback.
My assumption again, this will improve the ratio to 1 out of 2. My confidence is that it will be far better than 0.5
Who can I interview: Technical (hands on) roles for software development (for startups and bigger corporations). Experience 0-8 yrs.
What can I interview: CS fundamentals (OS, systems, networking, DB, Algorithms, Data Structures etc.), Technologies: C/C++, Ruby, RoR, HTML, Javascript.
I believe that cs fundamentals are the key though.
Pricing: $150 per interview (payable by paypal or direct account transfer to bank of america)
I think this proposal suits small to medium sized startups.
About me: I have BS (IIT G) and MS (USC) in computer science with more than 8 years of work experience. 2-3 years on RoR.
I have given tons of interview and taken tons of them too during my career.
You can checkout more about me at: http://shail2.co Contact me at: firstname.lastname@example.com, if interested. <comment><USER2> If I were hiring somebody to do tech interviews for me I'd want them to have broader skills than "what I learned in school + Ruby". But frankly, the idea of hiring somebody to do interviews for me sounds a bit like hiring somebody to sleep with my lover...it's a job that really should be done personally.

<comment><USER3> > it's a job that really should be done personally.

He's not proposing to hire the person for you, just to be an objective, presumably talented and qualified interviewer.

To use your analogy, he's the friend that vets the suitor, or offers a (solicited) opinion on your paramour. Nice line tho.

</comment></comment><comment><USER4> This is probably something you should pitch to recruiters instead.

I've talked to some tech recruiters in my area, offering to do training for them. I may need to talk to higher-ups, but the low-level people seem to actively _not_ want that knowledge. I certainly don't propose they understand OS design, assembler and mobile app dev down cold, but they need to know the difference between Java and JavaScript, for example.

One chap I spoke with recently - he called me for help wording something - didn't know what "JVM" was, yet was actively recruiting for Fortune 500 companies. Again, they don't need to be tech gods, but ... learn the language of what industry you're in.

Another was telling me they don't need to know much tech, because the clients were more primarily concerned about social fit in with their hires, and they could work out the tech details. While I agree social fit is a factor, too many of us have met those who can't FizzBuzz in an interview, wasting everyone's time (or worse yet, get hired and leave years of crappy legacy tech debt to deal with).

<comment><AUTHOR> Thanks a lot for this insight. This gives me another thing to try. Yep, if someone can put technology in lay man terms to recruiter they will be able to pick it up and be much better at their work. That will be win for everyone. Great idea.

<comment><USER4> It's a big IF. I've talked to a handful of recruiting companies and imo it's a perfect fit, but none of them have been interested - certainly not as a paid service. I think the turnover in tech recruiting may be too high for companies to consider paying for this, but... I may be wrong.

EDIT: Not _IF_ as in - can _you_ do it - but _IF_ they'll buy it.

<comment><AUTHOR> I think you are right. The turnover is high and hence little incentive to change the status quo. But if a recruiting company takes this approach, it will definitely have an edge. About the big IF, yes it is and I do not like to boast but I think I can do this very very well if not excellent.

</comment></comment></comment></comment><comment><USER5> To be blunt, I feel quite strongly that this is a bad idea. You might find business in this service, but only in companies which don't know any better. And if you can sell a service like this to that type of company, everyone (you, your client, their candidates) would be far better off if instead you sold them consulting services which made them more competent. Give a man; teach a man... right?

To explain:

Remember, companies are just formalized groups of people. What's the single most impactful component on a company's success? The people which make up said company.

The best candidates know this rule intuitively. They've completely internalized it. When these candidates imagine an excellent place to work, they imagine it first in these terms. These candidates will read the use of a service like the one you propose as a company shirking responsibility in an incredibly key area.

Yes, yes... it's _only_ a first round interview. You're just separating the wheat from the chaff, right?

Maybe the company knows that you/your service is/are incredibly competent at this task. However as a candidate I sure don't, and my first impression is going to be that the company relies on a third party to determine whether or not it's even willing to talk to a candidate? I'm sorry, but I'm outta here. I don't have time to market myself to two separate entities just to work for the final one, especially when I'm already being recruited by two other companies which are competent enough to validate their own candidates.

<comment><AUTHOR> Companies already do that through external recruiters. Just that they are not technical hence you do not get any tech questions from them. They only do filtering by grepping for technologies and experience in your resume. I would do a little bit more than that. Go into tech questions. I don't think it's very much different than that.

Correct me if I am missing something. Sorry it's a 3 day old thread but somehow every time I think about any downsides for the candidate I am still trying to find one really good one. It's not that I am trying to run this idea and hence I am biased. I am thinking in unbiased terms if you believe me.

</comment></comment><comment><USER6> I haven't done that many interviews, so take this FWIW, but I'd be reluctant to be interviewed by a 3rd party. I'd have no way of getting a feel for company culture, plus you probably wouldn't be able to answer MY questions about the company.

If you're focusing on the tech only, it's still another layer that adds more time and money, plus if it's specialized enough they'd probably do an internal review of code samples anyway.

<comment><AUTHOR> Valid points for sure. This is one of the downsides. But if you clear this round you are definitely going to talk to them. Its just that instead of answering those initial filtering questions to them, you would answer to me and I will convey that to them.

But I see your point and its a good point to consider before considering my idea.

<comment><USER7> Right, so the candidate has everything to lose and nothing to gain. The only beneficiary is the employer - which in the current supply/demand climate for engineers, makes the viability of this idea suspect.

<comment><AUTHOR> Yes, its a service offered to employers right now so beneficiary is the employer. But I do not completely agree that candidate is at a loss. If the candidate is good enough, he will meet the employer eventually.

<comment><USER7> > _" But I do not completely agree that candidate is at a loss."_

How is the candidate not at a loss?

Under the current system, a candidate can ask any number of questions about the company, their culture, their technology, and other things that are of extreme importance to the candidate in deciding which opportunities to pursue.

Under your system, none of this can be meaningfully answered except the "brochure" facts that are trivial to discover anyways.

Under the current system, a candidate immediately meets with a member of the company.

Under your system, he/she will meet the employer "eventually".

Everything about this system is a net negative compared to the status quo, for the candidate.

In the current employment climate for (good) software engineers, where demand massively outstrips supply, I simply do not see a system that penalizes candidates going anywhere. I really hate whipping this card out, but the last two times I've been actively seeking a job I've had no less than a dozen companies respond positively within _a single day_. I would be severely disinclined to do anything through an intermediary.

This goes double if I'm only passively looking. I'm not looking to jump ship, so I have zero desire to spin my wheels on opportunities without any information on whether this is interesting to me or not.

The climate favors the candidate, not the employer, unless the employer is exceptional. IMO your idea can only be viable if it brings something to the table for both sides.

</comment></comment></comment></comment></comment><comment><USER8> As someone who is responsible for hiring engineers at a small fashion company (~10 people), I can say that I would not use this service. It would be difficult to justify the cost.

Also, there is one caveat you are missing: the very last question, "Do you have any questions for me?" Interviews ought to be a two-way street, and a qualified candidate, in this model, wouldn't have the chance to ask me questions about our company. How might you address that?

Recruiting is hard, as we all know, because it is difficult not just to find _good_ candidates, but to find people _period_. At least, this is the case if you are a small business.

Job postings typically cost ~$350 - $500 to post on the well-known job boards. And I have yet to find a promising candidate via that venue.

So you are talking about a cost of 50% of what it cost me to post the job in the first place. And in all likelyhood, that candidate will be a no-go, and now we're out the money for this interview, on top of what is already an expensive proposition.

And if you've decided not to use job boards to hire (because they don't work), then you're already paying tens of thousands of dollars to companies who make money by placing candidates. By that point, I might as well interview the individual myself.

If you can find quality engineering candidates - and vet their interest, and their technical ability - then I would be interested. But as other commenters have said, maybe your services would be better marketed towards recruiting agencies themselves.

As an aside: recruiting is disproportionately, insanely, time-consuming and expensive. Many companies (Etsy, Hacker School) get huge press and accolaids for their progressive stance on recruiting. But if you are a small company trying to bootstrap, it is impossible to pay the fees (grant the scholarships, provide the space, etc) that make for good press and recruiting ability.

Help me solve that problem! Once I have more candidates than I can handle, then let's talk about more efficiently vetting them.

<comment><AUTHOR> From company perspective: Again, what is more important, money (which I am not charging a hell lot, if incase I am, correct me) or developers time. I am just reducing your cost on those interviews which would have failed already.

From candidate perspective: Do you talk to recruiters from hiring agencies? If yes, then you can see me as another recruiter who is much more technical. On answering the candidate's questions, I can obviously do part of the work. I am only taking one round so you have tons of more rounds to ask your questions.

<comment><USER8> I agree, it is not a hell of a lot. Certainly a drop in the bucket as compared to a developer's salary, even smaller compared to the employee's value to the company.

How many individuals would you interview before a successful hire? Let's say 20. That amounts to a $3,000 headhunting fee.

You can certainly make an argument for developers' time being worth more than $150/hr. Then again, the bottleneck isn't doing interviews, it's finding qualified people in the first place.

Then again, I know I'm not making $150/hr, even after you factor in benefits. (But what about opportunity cost? We can go down this rabbit hole too.)

Finally, at the end of the day, I'm not the one with the checkbook. I'd have to ask my boss. His first question will be "how do you know this will work? Have others had success before? What is your real cost of doing an interview?"

He gets people asking for money every day. So if I'm going to bug him about something - particularly if I'm going to try and chip away at our runway - then I have to have very strong guarantees that it will solve our business problem. And really, I'm not sure I'd be ready to throw my trust behind this concept.

So nothing you are suggesting is incorrect! I think it is an enterprising idea, modulo some of the comments in this thread. I'm offering, however, that for so many of the aforementioned reasons, for our particular company and the constraints I have, I would not pay money for this (since you "Ask HN'd") and there are other parts of the hiring process that are a bigger bottleneck than assessing fizzbuzz or someone's background.

</comment></comment></comment><comment><USER9> I actually did this for one of my consulting clients. It was a special situations though. I was the VP of Eng for a defunct company who's assets were bought by another. The purchaser needed to ramp up a team so I was helping with the interview process.

Parts that worked out well: 1\. I knew the product/service, so I understand what type of skill sets are needed. 2\. I know how to build a team, and the type of individuals you need for a good team. 3\. I am local, whereas everyone from the purchasing company was in another city.

Parts that didn't work out very well: 1\. I didn't know the direction the company was taking with the product, at least not clearly. 2\. I can't comment on the type of relationship or org structure to expect with the parent company. Mind you, no one would really know anyhow, cause nothing was established.

Overall, it worked out well in the end.

However, looking at your resume, I wouldn't hire you for this service as a hiring manager. You don't really have the management expertise to identify the right individuals, because often, personality is more important than technical skills, and it takes management experience to identify the right individuals.

Moreover, in my case, I was putting a team together from scratch, so I can put people together based on strengths and weaknesses. With an existing team, you don't have that option. So the value prop is even lower.

</comment><comment><USER10> I already hired engineers for several companies of very various sizes, and I can understand the value you're bringing. This said, if you're only going to be a technical filter, some companies will put your services against a combo of "recruiters + codility".

I personally went through codility myself for a company, and I found it decent, even though it has obvious disadvantages because of being online.

That said, if you feel like targeting bigger companies, I believe you should introduce yourself (or whatever company you're building) as a recruiter, but a strongly technical one, and then adapt your business model this way. It will scare companies less (newness equals risk), and it will make what you're bringing on the table more clear. Your value is in your technical skills.

I understand that the difference in your offering is that you're not offering companies to find candidates for them, but this is where you would become more useful than a method consisting of sending all the candidates to a service like codility.

All in all, I would use your services, but only if you solve a problem that my current tooling (recruiters I deal with, and online filtering services) can not solve, which does not look to be the case if I look at your current proposition.

<comment><AUTHOR> I agree. If I rename myself as recruiter, I fit in well in the system. In fact candidates will be happy to talk to me because I am much more technical than non-tech recruiters. I think my positioning is biting me :).

</comment></comment><comment><USER11> I like your idea from a company's perspective. I've seen many teams struggling to get good developers - Part of the problem is the existing team (it sucks technically) - they can't ask the right questions and end up hiring the wrong kinda folks.

You should probably explain a bit more in detail (on a blogpost maybe) on the matrix that you will use for evaluation related to techs.

I agree with few of the comments below too.

1) I'll not be interested in talking to you if it seems to me that you are a recruiter. But then - its me and people like me who are humbly confident about their skills - that's mostly not the case with everybody. May be you could partner with an employee -mostly silent- during interviews.

2) You could be doing a great deal of misdeed towards developers. I judge my prospective employer/team based on the questions they asked, how they asked, etc, etc. I've been trapped into a situation where I thought that the team is "very good" based on the interviewer - which turned out to be a disaster - bcoz the interviewer was brought in from some other team (read: excellent team) - but that's not what I was hired for.

<comment><AUTHOR> I think you said it correctly. And I should write a blog post explaining it better. The reason many companies screw up on hiring is because its difficult.

But to be honest, even after hearing lots of negative feedback from candidate's perspective, if I can smoothen out the interview process for a company, candidates will benefit too. Also, as I said in another comment, through experience (over a period of time) and technical knowledge I will be able to spot talent much faster. And I might end up helping candidate as well if I feel that he is actually the right candidate for a particular job.

</comment></comment><comment><USER12> I am going to be honest here. I will immediately stop the conversation if a company would pull something like this on me. For me, time spent with a recruiter is time mostly wasted: corporate speak, big magnificent mission statements which tell me only what I can find from the site. For me, the whole idea of talking to a tech person is to figure out very quickly whether aforesaid person is interesting, does interesting work and is possibly a good co-worker. Your service doesn't help me at all: you don't work for the company, your knowledge of the company's backend is going to be superficial unless you have touched their code and I couldn't care less if you were a good person or not because I am never going to see you.

Ultimately such a service is disrespectful of candidate time. Also, if you are a small or medium sized startup, you would be blindingly stupid to do purely a google style Algo/DS interview. You don't have six months to train the candidate and you would be better off focusing more on talking about your own problems, how to solve them and such.

<comment><AUTHOR> Hi eshvk

Thanks a lot for responding. I agree with few points but my argument against the rest is that I am not hijacking the whole interview process. I am just doing that round one which a junior person from the company would have done and I am hoping that if you clear you would have tons of chances to ask your questions and know the company well.

According to me, taking interview is an art. In fact, many times I have seen the person getting rejected by a company because someone inexperienced from the team took the first round and rejected him. I agree that companies should not do this. They should give another chance, but in real world when you have tons of resumes pouring in, companies end up doing this.

How about think along these lines, that if I really find you good. I will definitely make sure that your strengths are played in front of the employer really well and you are given due chance.

<comment><USER12> It doesn't matter if you are a junior person in the company or not. You are a team member, you should have a say in who gets hired.

> How about think along these lines, that if I really find you good. I will > definitely make sure that your strengths are played in front of the employer > really well and you are given due chance.

If I am really good, you will be wasting my time by not giving me a chance to tell me what on earth the company I am interviewing for is doing. Interviewing is a two-way street. It is not only about me passing your tests but it is also whether I will decide to like the company. That time that I spend interviewing with you is time where I still have no idea what the codebase looks like, what the latest problems the company is tussling with, why I would be a right fit.

</comment></comment></comment><comment><USER13> (with reference to ___automated_sysadmin_screen_test_ __)

While your idea is good I hardly see it scaling as it is hard to consistently assure quality of evaluations when done by hired consultants (You)

I have been an employer and I took a different approach, of putting technology at work.

What does that mean? Well we all talk about TDD (Rspec Driven Tests for your code), I applied that to interviews Rspec+Puppet [https://github.com/zalora/automated_sysadmin_screen_test](https://github.com/zalora/automated_sysadmin_screen_test)

This has worked pretty well for me and it will work for similar scenarios.

I was planning to build this into a service someday and have some pending plans on this, Anybody interested in sweat equity?

1.) This can become a service that recruiters can offer 2.) It can be subscribed on monthly subscription or per candidate basis 3.) Github repository shows the basic idea, it can be applied to other niche too.

Get in-touch if this interests you: a[at]parolkar[dot]com

</comment><comment><USER14> On the topic of incentives: Does anyone know if a system where a recruiter's compensation is tied to their proposed candidates _success /failure ratio_ as opposed to just the raw number of placements made? Or is it always just more implicit where if too many bad candidates are referred the company switches to a new recruiter?

<comment><AUTHOR> I do not think its tied to the ratio. Its just tied to the absolute hits value. Yeah, if the recruiter is sending tons of unqualified resumes, then a company would end up changing it. But that does not happen often.

</comment></comment><comment><USER15> What I'll say after looking for a job for a month now: There aren't many companies who even take the first step of emailing/contacting back after an application. I feel like this, if it was well defined and consistent, then it would be valuable.

<comment><AUTHOR> Yep, Thats the idea. Make it consistent.

</comment></comment><comment><USER16> I have gotten paid in the past for doing this. In addition to actually interviewing candidates, I also advised the client on the type of developer they needed etc. I actually have a lot of experience interviewing and making hiring decisions (and getting interviewed) so the client was fairly comfortable with this.

I like this idea since you are not having any conflict of interest when interviewing people. A nothing thing along these lines is the idea of getting pre-interviewed with your results shown online. Basically a crowd-sourced hiring platform.

<comment><AUTHOR> I love this fact about this idea that I am getting paid either ways so I do not have any conflict of interest. About the results shown online idea, I think candidates would not like that for the interviews gone bad. Correct me if I got it wrong.

</comment></comment><comment><AUTHOR> I am seeing lots of comments about candidates feeling bad about it. Just to clarify on that end.

Do you speak to outside recruiters. Do they ask you questions about your skills before fwding you resume? If the answer is yes, then I am just another recruiter who happens to be actually technical and instead of asking you "Whether you know this tech? or How many years of experience you have with this tech?" kind of questions, I am actually taking proper tech interviews before fwding your resume.

Thoughts?

<comment><USER12> You are pitching this idea amongst a group of people who hate the idea of talking to outside recruiters. To be honest, maybe your service isn't meant for startups in the Bay Area. Maybe outside there is a larger culture of talking to outside recruiters and going through that torture.

Oh, for the record. I have a firm policy of not answering technical questions posed by a non-technical recruiter who reads from a Q&A sheet.

<comment><AUTHOR> > who hate the idea of talking to outside recruiters

Wonder why? Could you list the reason. My guess is you would find my response in that.

</comment></comment></comment><comment><USER3> Interesting idea.

This is part of what employers think they're buying when they use a recruiter to bring in candidates. Of course they aren't getting what they pay for, and there's also the problem of inherently misaligned interests.

You might be able to sell that same service to job-seekers too. Many candidates are so poorly practiced that they hide genuine talent. Some are even aware of those shortcomings.

<comment><AUTHOR> Absolutely agree with that. A few rounds of practice before appearing will not hurt and will definitely increase your chances. But I am guessing selling it to fellow developers will be difficult. So I am starting with companies. But I agree with your idea and will give your idea a try as well.

</comment></comment><comment><USER17> Can I suggest that you pitch this service not to tech companies, but to recruiters? I think that's where the biggest disconnect lies - between tech recruiters and tech candidates.

You've got an excellent value proposition for recruiters, too. Anything that would improve their hit rate would presumably be extremely valuable.

<comment><AUTHOR> I agree that there is a value proposition for the recruiters but its difficult to make a service for them.

I think I have a value proposition for companies as well. I am reducing their filtering time (the time where technical folks from the company itself in involved).

Again, for candidates, if you speak to outside recruiters and judged by them before your resume get fwded, so you can see me as another recruiter who is actually technical and I am testing on your tech skills.

</comment></comment><comment><AUTHOR> I would also like to know if anyone has tried this before. What was the experience? Thoughts?

</comment><comment><USER18> If a one hour single-interviewer interview is a significant improvement then it seems like companies should do this themselves, I'm not sure what service you are really providing unless you are just a really good interviewer.

<comment><AUTHOR> I am saving lots of developers hours. I am saving critical developer hours during, say a launch, when you had to keep your candidate search on hold. It has happened to me multiple times. I was waiting to hear back from companies while they were busy launching a product. In real world it happens a lot. I know I cannot do later rounds and they should be done by the team themselves but initial round can definitely be done by me. And finally, I am reducing their misses which results in saved developer time.

<comment><USER18> > I am saving lots of developers hours

I don't see how this is really true. You say an interview can use up 15-20 developer hours and in some percentage of the failure cases you are saving that (and hopefully not failing some percentage of the passing casses, btw.)

My point is that if a 1-hour screening by a single developer is effective, I can keep it in-house and save 14-19 developer hours where you'd be saving me 15-20.

I guess I am actually assuming you are only spending 1 hour with the candidate, you never say that above. But my point is, unless you are uniquely good at interviewing, the amount of time you are putting into interviewing the candidate is the amount of the you are saving me.

</comment></comment></comment><comment><USER19> This is an absolutely great idea. More people need to think like this, just straight out offer a service. If everyone was taught this simple truth - Always Be Closing - there would be no unemployment lines.

</comment><comment><USER20> for me one of my deciding questions I ask people is "Any questions for me?" If they ask a lot, I know they are interested and I'll bring them in for an in person.

<comment><AUTHOR> But what if they lack the basic tech skills? I am not talking about tech as in knowing a language but someone whose CS fundamentals are weak.

Would you still consider? Obviously I am not talking about roles which do not require CS fundamentals to be strong.

edit: obviously again I am taking just round one.

</comment></comment><comment><USER21> What about all your jobs that you only stayed a year or less at on your resume? Has no one questioned that? Do you have any explanation for such apparent job hopping? Not that I blame you...

<comment><AUTHOR> Well, I have worked on mostly very early stage startups. Very rarely in a big corporation except my last employment. After that I have been working on my own startup.

As you know things change a lot in startups. Statistics show >95% of them fail. Hence the jump. I am not saying I jumped because they fail. But you work in a startup not because you want it to be next run of the mill company. You work in a startup so that it becomes the next Google.

But if my senses say that a company is not going to become next Google, I move on instead of wasting my time and companies time and money. I am not sure whether I answered your question but its more philosophical than anything else.</comment></comment>


How Remote Work Is Quietly Remaking Our Lives - <AUTHOR> https://www.vox.com/recode/2019/10/9/20885699/remote-work-from-anywhere-change-coworking-office-real-estate <comment><USER2> I've been working remotely for 10 years. 10 years ago, it was very difficult to find remote work. Now, it's much easier.

For anyone that wants to start a business while working, it's great.</comment>


International Obfuscated C Code Contest – 2018 Winning Entries - <AUTHOR> http://www.ioccc.org/years.html#2018 <comment><USER2> Fabrice Bellard (the wizard behind FFmpeg, QEMU, etc.) has his own entry, which I find amazing: a ~4 kB program that outputs a ~50 kB image (of Lena), in addition to being able to decompress other images. His entry's hint page: [http://www.ioccc.org/2018/bellard/hint.html](http://www.ioccc.org/2018/bellard/hint.html)

<comment><USER3> Can you explain a bit more how this works? I am not familiar at all with these challenges

50kB to 4kB is a 10x compression, it doesn't seem that huge, what's the achievement here?

<comment><USER4> From the author's comments:

"The uncompressed image is 12 times larger than the source code of the program which includes the image data and the complete decoder. The actual image data is 1220 byte long, which gives a compression ratio of 40. Using a JPEG-like algorithm would not be enough to reach this level of compression (the Lena image would be barely recognizable). So the algorithm is based on the latest advances in image compression."

[http://www.ioccc.org/2018/bellard/hint.html](http://www.ioccc.org/2018/bellard/hint.html)

</comment></comment></comment><comment><USER5> Christopher Mill's "Best of Show" pdp-7 emulator is seriously impressive. How is this even possible in such a small program?

<comment><USER6> An IOCCC Judge here. We are rather fond of this one. The "prog" variant allows you to build and run the mullender entry from the first IOCCC [http://www.ioccc.org/years.html#1984](http://www.ioccc.org/years.html#1984). The source is provided in the image, as is the compiler.

</comment></comment><comment><USER7>
      > # There is no 2016 IOCCC contest
      > # There is no 2017 IOCCC contest

Anybody know why?

<comment><USER6> An IOCCC Judge here. Sure, a variety of things! A competition can take about 4 full weekends of time ~128hrs total (Fri:6+Sat:16+Sun:10 x 4) to set up, judge and release the results. Getting 3 independent and very busy people coordinated with work, travel and major life events going on can get quite difficult. Recently we've opted to not start a competition if we do not pre- schedule the weekends for completing it! The result is that 2016 and 2017 could not happen.

<comment><USER7> Thanks! And thanks for taking the time to organise these competitions when you can, they're truly edifying.

</comment></comment></comment><comment><USER8> poikola:

        X enum  {T,F}  z; //True & False

        #define E {
        #define B }

Old ideas, but they'll still catch people out.

It's interesting to see how well, or badly, the syntax colourization in NeoVIM copes with the various entries.

</comment><comment><USER9> Yang's spoiler.html is actually super interesting as it's a live coding session for the entire program essentially. Also I thought the program name looked familiar when it said nuko, it's from the manga/anime Shoujo Shuumatsu Ryokou. It's a cute little thing that likes to eat technology, looks like this one's eaten four programs!

</comment><comment><USER5> Don Yang provided a video of how he wrote the code and transformed it into the obfuscated version (see spoiler.html). It is as interesting as the final result itself.

</comment><comment><USER5> Yusuke Endoh's "Best Use of Python" entry is a memetic masterpiece

</comment><comment><USER10> Anyone else feel that their URL should be cocic.gro ?

</comment><comment><USER11> hugged to death?

</comment><comment><USER12> I have tried navigate the page, but I still have not figured out what the goal was this year, who won, with which program and what has been obfuscated in it. Is there a better summary of this contest somewhere? Is there a link I'm missing?

<comment><USER13> The page / site really needs a redesign and a bit of writing done.

I'm actually of a mind to start a new webpage that does just that, but there might be some copyright issues there.

<comment><USER14> I'm not sure what copyright issues (writing or code or?) you are concerned about, but you should be able to get around them with a little planning. Just don't outright copy stuff.

<comment><USER15> Or just get in touch with the people behind the site and ask for explicit permission. Seems the simplest way to be sure, no?

<comment><USER14> "It is easier to get forgiveness than permission." \-- Words of wisdom from a career bureaucrat.

I think the simplest way is to just set up a site and make sure you cite your sources. The site under discussion here would be a primary source and should be listed as such on every single page that references any of the data found there.

Beyond that, it really depends on what the GP intends.

Start a blog and write a little blurb about each winner as separate blog posts? I don't think any permission is needed. Just write whatever you want to say about the project and note that they are the winner listed _here_ and link to the page where they are listed.

Start a clone of the site that adds additional info? Yeah, you maybe need to go talk to folks and find out if they are okay with that and get it in writing.

</comment></comment></comment></comment></comment><comment><USER16> And they say Perl is unreadable

<comment><USER17> Funny enough, the creator of Perl's previously well known accomplishment was winning these contests pretty much any time he cared to join. Take that as you will.

</comment></comment><comment><USER18> You know this competition is old when they still use .text files

<comment><USER19> Stuff that works doesn't need fixing.

It's very liberating, when you don't need to chase a trend.

<comment><USER20> The trend of three letter file extensions has been around since about 1989?

<comment><USER21> I'm more used to .md or .markdown, but apparently .text is also used for markdown files. Picking .txt (which I assume you're hinting at) would not be the most specific choice here.</comment></comment></comment></comment>


GitLab.com has free private repo's with 10 users - <AUTHOR> http://blog.gitlab.com/2013/02/27/pricing-for-gitlab-com-announced-10-users-are-free-and-no-change-until-july/

<comment><AUTHOR> Let me know if you have any feedback on the pricing. I liked the discussions around <http://news.ycombinator.com/item?id=5212207></comment>