Is the true YC? For all the talk about funding radical new ideas in their normal batches, they fund a lot of companies that look and act alike. So, when YC backs out of its own experiment because it turns out unexpected, it's not really disappointing; it's just a reminder of how seemingly conformist its attitudes are.

[1] http://idlewords.com/talks/web_design_first_100_years.htm

I haven't worked with Phoenix or even Erlang/Beam that much (though I've used Rabbit quite a bit). I think the overall model of the runtime is brilliant, but I'm not sure you need to buy in to the whole ecosystem to benefit from the learnings of it. There are actor systems for a lot of languages (Celluloid and Akka come to mind). Celluloid works nicely for weird long running things. I'm not totally sure how much it matters for your typical web app that would work fine enough with a CGI model (though I guess it's not totally different).

I've only played with Meteor, but I've used Node and React pretty extensively. React in particular is brilliant. It provides a nice way of thinking about the UI of your app in a more functional way. Of course, the devil's in the details, but it works pretty well. I'm less keen on Node as a backend language. A lot of backend code is between the lines, waiting on the DB or dealing with crazy errors. Node and JavaScript aren't very good at those things today. ES7 Async functions have some promise (hah!), but interoperating between libraries can be a little confusing at first.

Rails is an old friend of mine. You can do a lot with Rails, and it's almost sacrilege to say these days, but a well written monolithic, non-javascript heavy Rails app can be a joy to work in. It's pretty good for CMS type content; I've used it a bit to build various web stores to good effect. Things can get hairy when you try and step outside of "the Rails way", but that's less of an issue these days. It can also be a little funky using the asset pipeline with newer frontend libs, but there's that nifty source that packages frontend libraries as gems (the name eludes me at the moment).

To your latter point, I'd say that a lot of the time people embark on travel for the "wrong" reasons (some of which you mention, like boredom, social pressure, etc.) but end up discovering better reasons along the way (those illustrated in the destinations section). I think there is a stroke of admonishment in the article--asking the reader "why" _they_ travel. Personally, the more I demand myself to travel with purpose (as I have), the less I end up traveling. And my trips have been a lot more fulfilling as a result. But it's a little ironic in that, it's taken a lot of traveling to get to that point.

Comments URL: https://news.ycombinator.com/item?id=9702173

Points: 1

# Comments: 0

I've been playing around with full text search in Postgres, and I took this sort of approach when starting out, but then realized you I could just have the index be an expression.

So instead of (per the example)

  CREATE INDEX tsv_idx ON documents USING gin(tsv);

  CREATE INDEX tsv_idx ON documents USING gin(to_tsvector('english', text));

I'd say overall it looks pretty well written app code, especially if you say you're a beginner. One thing I'd like to point out is that in my (limited Swift) experience, stuff like this:

https://github.com/NikantVohra/HackerNewsClient-iOS/blob/mas...

...where you're force casting/unboxing/whateveritscalled a bunch of things is a smell. Sometimes it's unavoidable because of the weirdness between Cocoa and Swift, so typically your interface builder outlets will be riddled with that stuff, but for your own internal APIs, try and keep things as option-less as possible.

UI code is pretty challenging to keep organized, especially when platforms encourage using things like two-way bindings and keeping state all over the place. I'd recommend checking out Gary Bernhardt's talk "Boundaries" and Andy Matuschak's similar writings (sorry, can't think of anything off the top of my head), as they have some good ideas for demarcating the line between functional parts of your code that should be super clean and the anything goes world of external UI APIs.

Good luck and keep coding!

Comments URL: https://news.ycombinator.com/item?id=7897455

Points: 1

# Comments: 0

> In a move to bolster its new 'Anonymous' strategy, Facebook has acquired 4chan for $30 billion in an all-cash deal

> "It's been an incredible journey", said 4chan founder Christopher Poole at a press conference in Menlo Park, CA. "Our anonymous users have been the driving force behind 4chan, and we look forward to bringing that experience to Facebook"

Comments URL: https://news.ycombinator.com/item?id=7664180

Points: 3

# Comments: 0

* If you're a freshman you're likely going to change your major a few times. I don't know about UPenn, but unless things have changed EECS (and a few other majors/schools like Econ) is an "impacted" major, which means you need to apply for it once your preparatory classes are done.

* Start networking and trying to figure out what sorts of jobs you want to do sooner rather than later. I ended up doing programming after a somewhat circuitous job hunt the summer I graduated, but it could have been shorter had I started interning my last semester.

* Money is a real thing. Compare your financial aid packages and try and get a feel for the cost of living. If you're not a California resident, UC is incredibly expensive.

* Take advantage of the free/cheap things you get while in school. In particular, I wish I would have made more use of the gym/pools.

* College is a good time to start working on developing a good work/life balance. It seems obvious to me now, but schedule your classes in a way that's conducive to how you want to live. Don't kill yourself taking 3 really hard classes in one semester.

* Get involved in things you're actually interested in. It seemed like there were a lot of clubs in school that were basically shell games for "leadership" positions.

FWIW I transferred to Cal from community college. In my experience the instruction was, for the most part, the same quality-wise, but the classes were much smaller. I also ended up keeping a bit of a network from my community college, because there tends to cohorts of students that transfer to the same places.

See: https://developers.google.com/fonts/docs/getting_started#Sub...

So if you add a `&subset=all` to the example page requesting from Google Fonts, they'll end up looking pretty much the same (though I think some things are missing in the example, like the swashes on the Qs).

I discovered this in reading the Lobster font's documentation.

Comments URL: https://news.ycombinator.com/item?id=7052691

Points: 3

# Comments: 2

Comments URL: https://news.ycombinator.com/item?id=6138863

Points: 1

# Comments: 0

In any case, building this sort of thing is a pain. The most obvious problem is the size of the images. Glacier is an interesting backup solution, and had just come out around the time I decided to stop working on my app. A less obvious problem is raw conversion. All the best converters are proprietary, meaning that I had to piggy back off the Mac OS converter engines. Again, I never got to the point where I felt the product was worth the trouble of buying racking up a Mac Mini to run a little market test. Maybe I'm wrong.

I had a (frankly somewhat scattered) draft of a post mortem written, and since it seems like there's some interest in this subject, I posted it: http://scraps.bigbento.com/2013/05/30/hiatus.html