Hacker Newsnew | comments | show | ask | jobs | submit | amix's commentslogin

Elite accountants usually get promoted into CFO positions, where they are very important and get a huge paycheck. There is a huge difference between a good and an amazing CFO.

I think 10X people exist in any area, including accounting and programming. E.g. John Carmack, Linus Torvalds, Poul-Henning Kamp. Some top accountants can be found by looking at CFO positions of huge companies.

These people are very rare tho' and most of us have probably not worked with a 10X person. Just like most of us have not played football with a "Ronaldo-level" player.

-----


There are probably also 100X people - and they're mostly unemployable in any conventional sense. (Maybe Wolfram and Kurzweil?)

I think the bar for top talent is higher than is obvious, and it's lower than it used to be.

It's not at the level of 'smart and gets a lot of stuff done' - it's at the level of good as McCarthy and K&R and the guys (and occasionally the women) who invented coding in the 60s and 70s.

Most of them have been forgotten, but many of them had phenomenal skills - the kind of people who would work for a couple of months on a project, type in all the code on a single day, and have it work perfectly first time.

Or who would sketch out a fully functional timesharing OS for a new hardware architecture over a weekend and have it finished and working a couple of months later.

Or the small team at Xerox PARC led by Charles Thacker who decided to clone an entire DEC PDP-10 mainframe as a side project, because management wouldn't let them buy one and they wanted something nicer to code on.

-----


The list of speakers looks fantastic! This said, I think the list lacks diversity. I think it would be great to have someone outside of SV in it (e.g. Jason Fried, Jeff Bezos etc.) One of the better Startup School talks I seen was from DHH (that presented another way of building a successful company).

-----


But then they'd have to cover stuff like focusing on sales from the start of a business, developing a business model, and making money (from customers) ASAP.

(In case of confusion, I have my tongue in cheek ;-) These topics will surely be covered in the content somewhere if it's about building a business.)

-----


There is a better way to do this by using bitmaps (especially bitmaps in Redis). I recommend looking at https://github.com/Doist/bitmapist

-----


Technically HyperLogLog works on bitmaps, this library leverages this fact and uses Redis bitmaps instead of an in-memory implementation.

Although we are fans of Redis, if you implement it natively you can avoid network latency. Implementing it natively is not a problem because of the commutative nature of HyperLogLog

Further, If one is planning to use Redis it will be better to use built-in HyperLogLog datastructure provided by Redis 2.8.9 as documented here http://antirez.com/news/75

-----


This presentation is tasteless and totally takes any seriousness that should be related to making and promoting an OpenSSL replacement. I personally can't take it seriously and I would recommend hackers to think about what image their presentation and design conveys.

-----


When it comes to security tools, one uses a different approach to selecting your tools. At least, you do if you want to be secure. The best presentation and the prettiest website are nowhere in the selection criteria. You look at the history of the people involved, primarily. What have they done in the past? Was it believed to be secure by other researchers? Is it secure today because they have actively maintained it? Have they used good practices that allow their code to easily be audited by others? Have they welcomed feedback from other competent developers?

Using Comic Sans and bitching about the quality of another project is irrelevant in this scenario. OpenBSD project brings with it an almost two-decade history of seriousness about security that I think one would be a fool to ignore.

-----


When Stee Jobs got kicked out of Lisa development and took over Macintosh he raised a pirate flag, sticking up a finger to the suits have a long and storied history in the business. The people that take offense at such things aren't people you want on your side anyway.

-----


To me it conveys that they are a group of grognards that can't be bought and never mince words or use euphemisms, even if it upsets people. Precisely want you want for developers of a security library.

-----


Do you mean the comic sans or calling the code terrible and (presumably) its developers incompetent?

-----


I can recommend this article that explains OT really well: http://www.codecommit.com/blog/java/understanding-and-applyi...

-----


Are there any great open-source implementations of OT? Last time I looked there were some, but the quality and popularity of them was questionable.

-----


https://github.com/share/ShareJS

That guy also has a C library too. IIRC he used to work on the wave team.

-----


(Author here)

ShareJS also supports collaboratively editing arbitrary JSON documents. Support for seeing everyone's cursors is being added at the moment - there's a sandbox kicking around here if you want to play with the prototype version: http://sharejs.org:7007/

-----


https://github.com/Operational-Transformation/ot.js/

-----


For collaborating on general JSON documents, you ought to check out ShareJS; it is a great library.

However, for more complex tasks like rich text editing (at least richer than what markdown supports) you'll need to have an implementation tailored for the task.

-----


Professional snooker is still very popular and the best earn millions of USD pr. year. So the situation between snooker and bowling isn't quite the same.

-----


I like the general idea of this project. I think tho' it smells like a enterprisey Java project that's coded in JavaScript (at least by looking at the code and how things are structured).

-----


> it smells like a enterprisey Java project

I'd hope you'd have something more constructive to say.

I'm not saying enterprisey is good, but, damn, evaluate it based on the actual design, rather than running away screaming because it uses IoC and publish/subscribe.

-----


I am evaluating it on design and I think the design looks more like a Java codebase than a JavaScript one. I don't think this is a positive thing since you should not try to emulate Java idioms in JavaScript (or vice-versa).

A small example is usage of XML files for configuration of aliases. Very few people use XML files in the JavaScript world - - while it's almost a standard for Java projects.

In general, the more I look at the codebase the more messy it looks like. They could have built something much simpler that solves the same problem.

-----


It has come out of enterprise focused development - there's no getting away from that. And we have enterprise customers that the toolkit has to support.

However, enterprise is in a state of convergence right now. Those that would not previously work at "Enterprise" orgnisations are providing great value there. Those that have been part of the web development community for some time will hopefully attest to that.

So, what we're trying to do with BRJS is follow that convergence; and be part of it. Some software engineering concepts traditionally associated with enterprise shouldn't be dropped simply because of this association. Similarly techniques and tools that wouldn't have been found in the enterprise shouldn't be dismissed because they don't conform to the expected stereotypes.

For example:

- encapsulation - separation of concerns - interfaces (In JavaScript: arrgghhhh!) - think contracts (function names and signatures). We've had lots of discussions about this but them continue to delivery value when building a maintainable app - services via an IoC/Dynamic Service Locator (see Angular) - PubSub - hopefully Addy Osmani and a number of other solutions have done enough to clarify why this is useful

All these ring of enterprise. But they're actually just good and simple software engineering practices.

When building large JavaScript apps it's about getting the balance right and we're hoping that as part of this open sourcing project we can do that.

One obvious thing that will still stand out as needing improvement are the deep directory structure (from Java). This is high on our list of improvements. We also only export to a WAR right now, but flat file export is also a high priority.

-----


It was basically create by people who didn't have much JS experience so that's why it looks like Java more then JS, in fact that's why it's Java and not node. You're right it could have been much simpler. It used to be much worse.

-----


It was created for people without JS experience, specifically Java devs that moved from back end to front end teams to write webapps. Things have since moved on and we're bringing the coding style, among other things, more inline with new practices.

The tooling itself is Java since a lot of Caplin's customers still have't adopted Node, in fact some of their ops departments are completely opposed to it, and just because it isn't written in the same language as your front end code does't mean the tooling and principles are any less valid or useful.

-----


Don't forget the XML :) Seriously though, the project does look pretty cool.

-----


Allegation that a wife of a founder can read private chats at GitHub makes me question GitHub's privacy and security... I would love if we would have a statement of GitHub on this matter since it would be a huge privacy breach (and something that would make us move all of our private repos outside of GitHub). (posted this as a comment on the article as well)

-----


That is largely the stand out of the article for me. I know this story will be forgotten and buried in no more than a week, but until they address this, I'm going to use BitBucket instead.

-----


I was also thinking this while reading this (and I am very new to Go). Here's how I would write this in Go: https://gist.github.com/amix/9517995

I think this is the idiomatic way to implement this. It will lock the account every time you try to deposit to it (so other goroutines can't do it).

-----


Using mutexes isn't considered as idiomatic Go code

-----


Mutexes are absolutely idiomatic Go code. In fact the Core developers on the ML will often suggest them as a simplification over goroutines for synchronizing access to a shared resource. I'm not sure where you get the idea that they aren't idiomatic.

-----


Probably by making the mistake to read the Effective Go.

http://golang.org/doc/effective_go.html#concurrency

"Do not communicate by sharing memory; instead, share memory by communicating.

This approach can be taken too far. Reference counts may be best done by putting a mutex around an integer variable, for instance. But as a high-level approach, using channels to control access makes it easier to write clear, correct programs. "

-----


I don't really think what I suggest goes against the article you link to. It basically says: use channels when appropriate, but sometimes the best approach is to use locks.

E.g. An bank account is shared state (similar to a reference count) and the best approach is to put a mutex around it instead of fighting with channel synchronization.

-----


There are no implications here, it's stated pretty explicitly:

"Reference counts MAY be best done by putting a mutex around an integer variable, for instance. BUT as a high-level approach, using channels to control access makes it easier to write clear, correct programs."

There is a difference between what someone with a background from other mainstream programming languages might think would be the best approach to locking (mutexes) and the idiomatic Go approach (unbuffered channels).

-----


Well anything other than direct channel <-> goroutine is not considered idiomatic.

-----

More

Applications are open for YC Summer 2015

Guidelines | FAQ | Support | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: