bigbento

Oh, that's what I meant by "deauthorized the app". I removed it on the Google side, and shortly after even got an email from Unroll.me saying that it no longer had access. So I was surprised to see an email a couple months later saying they'd found more stuff to unsubscribe from. It could have been a bug or just a message they sent to everyone who'd unplugged their email, but was quite jarring.

I was a little creeped out when--long after I deauthorized the app and enabled 2FA on my Gmail account--I got an email from them saying "We've found 141 new subscriptions". I wonder if that was just marketing spam, or if they have a weird way of accessing my email still.

I voted for Maciej because I admire what he's doing and I'd like to think that I "get" him (though I don't know him personally). I cut my teeth in this industry working at a startup that's still bootstrapped and profitable, and I share his vision of building an internet to "CONNECT KNOWLEDGE, PEOPLE, AND CATS" [1], instead of whatever insane internet people are dreaming of these days. Yes, it's a bit of a political thing, and while it might be a protest against the current industry culture (can you honestly blame us?), I don't think it's just a joke either. I think Maciej has a great intuitive sense of how people, technology, and culture interact, and he's good at expressing that; his ventures are certainly worth spending the equivalent of a single employee's recruitment fee.

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 used Laravel, but PHP tends to be relatively easy to get a development environment running as well as deploying on shared host type environments. On the flip side, the application becomes ever intertwined with the host environment, and beyond that, PHP libraries and frameworks tend to lack a lot of discipline that you find in other languages (that is, you find yourself pondering things like, "what if I were running this across many boxes, oh it'd just break..."), so 12-factor readiness (which helps when you want to run your app on more than one machine) tends to be an afterthought.

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).

I didn't take the end as "just a collection of destinations", but rather a selection of vignettes illustrating the various reasons one might travel to a particular destination. There are a multitude of reasons one might travel, and the author's pointing out some good ones, along with a personal reflection on that. The sections on the beach and the pumping station particularly spoke to me; the former because I'd previously seen a beach vacation as an indulgent waste of time (but have since come around), and the latter because, though it seems almost like a platitude, not enough people encourage others to make a trip planned around what they find particularly interesting.

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.

When I worked at OkCupid Labs, we normally just did daily lunch ad-hoc. However, we set up a little app that would organize a weekly lunch "date" where people would have a one-to-one with someone from a different team. I had some pretty interesting conversations come up from that, and if I were approaching this "problem", would start from there again.

To get optimum performance with PostgreSQL full text search you need to create a column to store the tsvector values with an index on it. Then you need to fill this column with the tsv values and create a trigger to update the field on INSERT and UPDATE.

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);

doing something like

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

Is there any reason you wouldn't do this? For multi-languange you you'd have to detect the language of the text, but there's no reason you couldn't parameterize that too.

Yes. I find it a pretty practical format; for what I read it's cheap, light, and reliable. Not to mention that there's a lot of quality content available only in paper books.

Have they fixed testing with Swift yet? I am normally a pretty test driven person, but honestly, Apple makes it pretty annoying to use tests with Swift, so I don't blame you for your lonely scaffold.

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!

When are we going to hear the news?

> 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"

Some things to consider:

* 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.

You can request all subsets to include a font's ligatures with Google fonts.

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.

I'd be curious as to where Reel (both on and off Rack) lands in there as well.

Over the past few years, I worked on a few versions of this as a side project. The last iteration didn't do the backup itself--it connected with your Dropbox, sync'd the raw images, and processed them at a preset +-2 EV, and 3 color temperatures. The image results were good, but honestly I never found it particularly compelling.

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

One of the things I love about Sinatra is that pretty much everything you need to know is in the README. Otherwise, understanding how Rack/your web server/your gems work is useful. From another angle, Paul Dix's Service-Oriented Design with Ruby and Rails has a lot of examples of using Sinatra in a variety of applications.

The tone and nature of this oddly reminds me of a point in the video game Earthbound, where part way through the game you take a coffee break with one of the NPCs. It serves no purpose other than to give you a break and reflect on the game.

Amazon's Elastic Beanstalk is a good compromise in this regard. I've been using it to develop some JRuby/Sinatra backend services, and though it's not quite as simple as Heroku, it's pretty close. Since the applications are just EC2 instances underneath the hood, you can tweak the server image quite a bit too, which is nice when you need to run some odd binary programs along side your web application. I haven't played around with Beanstalk's autoscaling feature yet, but that might come in handy for processing background jobs that fluctuate a lot.

Like many others, having dealt with both issues of 1) building one of these single-page frameworks on the client side, and 2) the prospect dealing with two application, I've always been wondering "is there a better way?"

Now, if you go with a service oriented approach, as has Twitter and Facebook, you can build an API your JS client can talk to. One issue with this is, developing these kinds of services assumes a sort of stability, which can't be taken for granted in the earlier stages of application development.

Of course, there are frameworks that help speed this sort of thing up, but it makes it difficult to leverage libraries outside of the framework, as they're intended for single page applications. And you're still stuck with writing a client for each of your target platforms (JS/Static/Mobile Web/Mobile API).

When I first encountered Mustache, the dream of having one view rule them all tantalized me. So I started playing around with it, and have been working on an experiment I call "Marionette". It's basically the antithesis of something like SproutCore, in that the client is fairly dumb, and more or less draws the same as the server using an exposed API, and any widgets would be added on top in the form of your regular MooQuery libraries. I have a lot of work to do with the execution (history navigation is broken, for starters), but I think the overall premise has merit.

I'd wanted to polish it up a little before showing it off, but this article has inspired me to get it out the door. "Release early...", and all that.

https://github.com/bigbento/marionette https://github.com/bigbento/marionette-demo

I can empathize. I've always found date-related bugs to be the hardest to track down and messiest to resolve. Especially in applications consuming data from a huge variety of buggy input formats ("So it's a server in Australia, but their application layer adjusts time +36000 seconds and their durations are listed in days, but it's daylight savings here...")

"Well, just don't fly the shuttle over New Year's" seems like a reasonable enough workaround for an otherwise highly planned out program, especially when, as a commenter in OP points out, the missions were only intended to run weeks at a time to begin with.

Some thoughts on the design, which I'm not terribly excited about:

When I read Google News or a newspaper's website, I scan a lot of headlines. Even that level of summary helps keep me up to date with what's going on. Memsparx gives me four stories by default, with no clear indication of the gravity of them.

The graphic approach is interesting though. I think you could go somewhere with a "field" of images in different sizes.