cmbaus

I have to agree. I've been working on a prototype for an app that I think is pretty cool, but I'm afraid to release here it in an early state. I'm concerned the focus will be on what it isn't versus what it could be.

It is one thing to provide constructive criticism. It is another to be condescending. Unfortunately, and maybe it is just human nature, but I think we see too much of the second.

I'd love to see more help in getting projects off the ground. That would be a great compliment to Y Combinator. Since many Y Combinator alum are on the site, they could use their experience to help HN contributors who aren't in the YC program.

What the author is alluding to is that centralized messages queues can cause catastrophic failure over[1].

Industry knowledge of how to distribute loads has improved significantly in the past 10 years. I wish the author would touch on some other options like using a load balancer with consistent hashing[2].

[1] http://martinfowler.com/bliki/CatastrophicFailover.html [2] https://en.wikipedia.org/wiki/Consistent_hashing

I have a question regarding the Puma architecture.

Does it use async/evented connection handling combined with a thread pool of workers handling requests?

Don't know. It has been shown to work.

One of the major benefits touted by the proponents of Agile was that it modeled how successful software teams worked. Well here's a successful software team and this is how it works.

For most teams it is probably a truly bad idea. But it shows there is more than one way to do it.

Update: The more I think about it, maybe this isn't so crazy. Wasn't Erlang built to work this way, so engineers could modify a telecom switch without taking it offline? As systems get gigantic it gets very difficult to have a staging environment that mimics the live site.

This is my all time favorite HN comment!

For everyone who claims there is one true way to write successful software, it should be noted that one of the most popular (or least influential) sites frequented by developers was built on the live server using the REPL!

Maybe PG is the exception that proves the rule, but damn that's awesome.

One suggestion. I would make the description on the landing page more informative about the service you offer rather than how exceptional you are. It took me a while to understand what your product was.

For instance, on the Y Combinator home page PG isn't mentioned. Instead the concept of Y Combinator is outlined.

Here's an example of some of their content: https://www.youtube.com/watch?v=RsS4uCRrN_Y

I'm not sure I would go as far as calling Grunt a complicated OO framework, but the first thing that crossed my mind when looking at Grunt was 'why not use make?' It may not be perfect, but at least you get incremental builds.

Can someone vote me up so I can get my karma above 1000 :)

Presentation is pretty important in much of the business because that's how the products are sold and fees justified.

Let's say your firm trades bonds. Your product is your expertise in trading those bonds, and you have to sell that expertise. How are you going to do that? Much of it is still reputation, but the days of closing a pension fund with a few martinis and your good looks are coming to an end. You have to have the numbers to back up your claims.

I don't think that is true. There are a lot of new firms targeting individual investors (even some YC funded). You are going to be competing against the brokerages themselves which are constantly pushing more sophisticated platforms for active traders.

Most individuals should not be active traders, and for non-active traders then your product has to compete against something like the Vanguard lifecycle funds which are damn good and cheap products.

I really want to believe there is a value add in products like Betterment, but is Betterment really significantly better than a Vanguard fund? I doubt it.

It might be possible to charge more than Vanguard, but I think that most who do are preying on the ignorance of investors, and that's not how I would want to make a living.

Certainly Excel works for many people, but there was a significant number of users who wanted a vertically integrated presentation/reporting platform. I think there is still room for innovation in this area.

You might be able to do something with the correlations of the index returns and stock returns, but I doubt their would be enough information there to depend on results.

Factset's main defensive position it that they have direct feeds from most of the money managers and can do attribution analysis on their trade data overnight. That might not be as hard as getting the market data Bloomberg has, but still a pretty big step.

Also the performance attribution that FactSet provides requires constituent data from the major indexes. Money managers are particular as hell about their indexes, so you can't just provide generic indexes, unless you first convince them that the generic indexes have value. That could take years.

Not all Bloomberg users are traders though, and that's where I would try to challenge them. I worked on software for many years that was used side by side with Bloomberg. Many of our customers were Bloomberg customers as well -- although our software was a bit more niche and we didn't hit the heights that Bloomberg did. But when I doubted if we were in the right business, I would look over to Bloomberg and convince myself that the money was there for the right products.

While Bloomberg has almost any conceivable piece of data in real time, what they were missing was presentation. For instance, if you wanted to make a presentation to your board which demonstrated your value as a money manager, you'd have to leave Bloomberg to do it. That's how we were able to share space with them. But I've heard rumors they are moving in this direction now.

I also agree with the author that the data is really the lynch pin. Some commonly used data can be very expensive to acquire if you are able to get it at all. For instance try finding out what stocks and weights make up the Russell 2000 index (and then legally redistribute that data). We were fortunate in that we got in the business when data vendors were willing to negotiate with small software vendors. And much of the value we offered was in those accumulated contracts.

Once those contracts are in place it is very difficult for either side to cancel them without pissing off their customers. For instance a couple years ago FactSet and Morningstar got into a spat and FactSet's contract to provide Morningstar data wasn't renewed. All hell broke loose on both sides. They made a deal. Data is pretty big chasm for a startup to cross. And users are particular about what data vendors they use, even for nearly equivalent products.

There have been some reasonable exits in the financial software business that don't get much play in the Valley. For instance BlackDiamond sold their reporting package (again presentation) to Advent in San Francisco for about $70million and eVestment has been taking on investment and growing like crazy. But neither of those companies competed head to head with Bloomberg's core business. But they are big enough markets that I could see Bloomberg wanting to grow into them.

In general, if you want a slice of the market that Bloomberg is in, I don't think it would easy to do it head on over data. You have to outflank them where they are weak, and hope to chip away at their mindshare that way.

I think you are drawing conclusions from a small sample size. I've had the exact opposite experience.

I had this exact experience yesterday.

I was reviewing the code spit out by a Yeoman generator, while reading some Angular docs (admittedly out of order), and I has confused about how variables were being defined. I finally read something that explained what to do (add a variable using a specific naming convention to the function declaration). I realized the framework was doing some sort of backhanded meta-programming, and I didn't feel so bad for not understanding what was going on.

The problem with this is you can be a pretty knowledgable JavaScript programmer and still not understand the code or the documentation. For this reason, I've never been a fan of meta-programming in general. Not only do you (as an application programmer) have to understand the language as defined, you have to understand other frameworks' reinterpretation of the language. If you bring in multiple frameworks that do this, it quickly becomes more difficult to reason about what a program does by simply reading the code.

I took a business meeting in Houston one time, and my colleague kept telling me that the office was "in the mall." That seemed very odd to me, but there was a massive office building attached to the mall. Not a bad idea I guess considering the summer weather in Houston.

Joking aside, there is something to be said about doing CM with the shell.

If somebody created a list of requirements for the perfect language for doing CM it would probably be similar to:

- Always available on every machine

- Proven reliable and stable

- Built to interface with the OS and other utilities

Hmm, that sounds a lot like the shell. If your application doesn't already depend on Ruby, bringing Ruby in as a dependency, is a lot of extra overhead. There is something to be said about this concept, but it should be shell all the way down.

I agree. This would be far more awesome if you could install it with a fucking shell script. It is called fucking shell scripts. Not fucking ruby scripts.

But there is a lot of tooling required to solve problems seen by common web apps.

Node is doing it differently, and it has advantages and disadvantages. One disadvantage is if you are doing CPU bound work, you will have to consider how you design your app more carefully. But that's the case with any language or platform.

Event driven servers have been around since the dawn of the internet and the select() call. Node has simply made it easier to write them in a higher level language. I personally think the event model makes a lot of sense for writing network servers, which web servers are. Also having a high performance HTTP implementation built into a platform for building applications for the web is a significant benefit.

I think two prevalent models are going to emerge for writing concurrent servers in the future. Event driven platforms like Node and actor/messaging passing systems like Go and Erlang. The languages and platforms that do not do those things well, I believe, will become less popular.

Yes it is true, if your app is CPU bound, the event driven model has limitations. But many applications are not CPU bound.

Using synchronous I/O is only simpler if you never have to synchronize threads, which you always do.

After taking a closer look at Discourse, it seemed to me that there was something amiss about how the Ruby community handles concurrency -- non-blocking servers (thin), with blocking database I/O (ActiveRecord), behind a round robin load balancer (nginx), combined with external processes for asynchronous tasks (sidekiq). That is a lot of tooling to handle concurrency. Comparatively I think Node has some advantages.

I am a proponent of Node, not because I think it is perfect, but I do think it does many things right. If you are building a significant web app you can't avoid JavaScript. And it is nice to be able to use and move code between the client and the server.

Also, this might sound weird, but I think there are some benefits to forcing developers to think differently about blocking vs non-blocking operations, since there are magnitudes of performance differences between the two. I think the outcome will be better architected and performing applications, but that's just a hunch.

Maybe Erlang and Go do concurrency right with message passing and light weight threading models, but they haven't taken the web development world by storm either. I think Go has a good chance, but time will tell.

During the PC boom in the 90s many of the hot products were productivity apps that allowed non-programmers to do "computing" (for lack of a better term).

- Access/dBase/Filemaker

- Word/WordPerfect

- Excel/Lotus

- Photoshop

- Harvard Graphics (if anyone remembers that one)

- Pagemaker

- Corel Draw/Illustrator

These were the types of apps that many young programmers, myself included, wanted to work on.

After the internet happened effort moved away from productivity apps, and towards communication apps. That's where all the hyper growth was, so that's understandable.

In the meantime, not much has really changed with productivity apps. The big apps from 90s are still the big apps of today. But as browsers have improved significantly in the past couple years, I think there is going to be a resurgence in web based productivity apps. Webflow is a good example. They are basically building a traditional style productivity app in the browser.

   "build": "npm run build-js && npm run build-css"

Ok I see. That's sort of a poor man's dependency checker.

To be honest, I didn't realize that npm could be used as a task runner, but now that I do, I'm wondering what all the fuss about Grunt is. Why bring in yet another meta-tool into the chain if npm (which is basically a requirement) can handle task execution already?

I have question as someone that is still fairly new to node. The article recommends using npm for running tasks (for instance starting the application), but others recommend an external tool like grunt. Is it more idiomatic to use grunt or npm for these tasks?

This is an interesting idea. I could see it being used by senior and junior engineers alike.

There are times when I'm working in an area where I do not have experience or expertise and think, "it would be nice to have a specialist review what I'm doing here." Sometimes I'll ask a friend, but you can only do that so often. It would be better to pay for that advice.

This could be really useful to generalist developers.

@angersock That's a good point on the number of points. If I downsampled the yield history to monthly yields, that would probably help the performance.

I've been playing around (http://yield.io) with Flot, which uses canvas and rendering speed seems pretty good, but resizing gets a bit wonky when there are multiple canvas elements on a page.