jblock

Garmentier | Senior Software Engineer | Chicago, IL or Remote | Full-Time

Garmentier is hiring! We are a quickly growing Fashion + Technology startup based in Chicago. We have created the first all-in-one online platform for Stylists and Personal Shoppers to start, grow and scale their businesses.

We're looking for a full-stack generalist to join our growing team! If you're interested, you can read more about the position here: https://cutt.ly/garmentier-senior-software-engineer.

You can also read more about our interview process here: https://cutt.ly/garmentier-tech-interview-process

Send a message to jason @ garmentier.co if you're interested in learning more!

TIL that I'd been using items in this list for reference without realizing that I had been working with Josh (OP) at my day-job the whole time!

Hahaha, thank you. I was also trying to be curt and funny, but I guess the HN community takes their Ethereum seriously :D

I have no idea how Etherium or the blockchain works. I'm sure that it's all incredibly important and technically impressive, but these all sound like fake words that your parents would use to describe what happens when they try to update iTunes.

Can't you do both?

You are entitled to your opinions, but why do you see this as forced? The quotes you present show a piece of prose intended to evoke a mood and set a scene. None of it feels forced, or thick, or unnecessary.

I think it really depends on your implementation. For readability, having a `UserStore` and `MessageStore` in one place might get to be troublesome, especially when it comes to separating out business logic. But that said, things like `Om` like to push the idea of a single application state object, so I can forsee an implementation where you have multiple `Store`s that sit atop a single `ApplicationStore`, such that you deal with the keys of `users` and `messages` separately while they are attached to the same parent `ApplicationState` object (which can be immutable and persistent as well).

Absolutely. At first I was excited that there was so much activity. Simultaneously, it intimidates many engineers I talk to because of how much fragmentation there is.

Thankfully, the footprint of each framework is relatively small. I'd try to pick the one that seems to be the least encroaching (e.g. not using tons of custom components, something fairly agnostic about underlying data structure/data fetching methods). That way, if the tide suddenly changes, you're not buried up to your toes in messy, dying code.

You can also get by with React on its own! We've got a few areas in some of our Backbone apps where we've just decided to use raw XHR requests to fetch data (and nothing wrapping around the objects themselves).

So the TLDR is that I don't have a good panacea of a Flux library to recommend, but that shouldn't stop you from investigating React as a view mechanism in your applications.

I wish this was the top comment :(

While your points are reasonably valid, I think it's missing one grander conclusion: the tools are simply that, tools. Above all else, it's what you make with them that matters.

As an engineer, I might be interested in the implementation details of a particular system, but as an end user, I don't give a shit.

And with that, it's up to the engineer to determine the appropriate tool for the job, as has been the duty of engineers since man carved the first wheel.

All I want is a fast, functional Gmail.

Any shine they want to put on it is fine by me.

Watching Veep right afterwards is a nice (and just as brilliant in other ways) contrast.

HN gets a lot of post about acquisitions and whatnot, but I feel this is probably one of the most important in recent memory.

The implications of taking this talent into consumer robotics (or augmenting their presence in the defense community) will ripple through the tech world.

I recommended my friends endorse me in Falconry

Probably, though the thermal shock might be a lot more exaggerated (hot-ass days, cold-ass nights).

But the solar power mechanism would definitely be more viable in the desert.

Regardless, I still don't want a big magnet in my pocket

Design note: that slider is awkward. There's no indication that it's moving until it hits a discrete point.

Nice idea. You should probably make it clear that it uses Google auth, though.

I had never been to SF before last summer. This building was right across from the bus I took home every day. And every day I wondered: what was in that windowless building? Never was it not an imposing sight.

Even after I found out about this, it freaked me out; especially that it's right in the heart of downtown.

I asked them about this in an interview.

Simply put, they said that if you don't feel comfortable working on a project, you just say so, and get moved elsewhere.

"So the main reason to intern is to just become a better coder? Doubtful. Just to be completely blunt, the main reason college students intern is to have a secure job after graduation."

False. 100%, completely and entirely, false.

School is frequently grounded in theory. More often than not, Internships are on actual products. Being able to traverse/understand source code and build productively into an existing product is an invaluable skill as an engineer.

Not only that, but it's during the internships that you meet all the people from outside of your collegiate bubble and where you FIND the people you want to build with. Not only that, but a fair amount of (us) students are consumed by loans, and any sum of pocket change (though the thousands of dollars you make at a place like Facebook or Google is in no way trivial) is invaluable. Not to mention that you get that building experience at the same time.

And yes, internships help you get a job. There is nothing, NOTHING AT ALL undignified about doing that.

The mindset of building for the sake of building is great! No qualms there. I think your view on internships and their value to students is a bit oversimplified.

Project decisions aren't binary. I'd assume that people that worked on Reader didn't work on this.

Not to sound catty, but try to tell an elderly person what StickyKeys is

It gets testy around walls.

My experience is that in a moderately-lit situation (or a low-lit one) the thing works pretty great.

This is Apple Mail in Linux. A good idea, but not worth this hyperbole.

"San Francisco please acqui-hire 9000 dogs"

I can't wait for this debacle to stop being news.

Google cancelled a product. It let you read websites quickly. There are other ways to do it. Moving on...

It's an interesting perspective on the man in light of all the ruckus about his film and the bankruptcy of Rhythm & Hues (who did the Oscar-winning effects for the film and ultimately fired 250 people in the past month):

http://www.guardian.co.uk/film/2013/feb/26/ang-lee-visual-ef...

He's got talent, that's for sure. I suspect much of the flak should be thrown at the industry rather than at the filmmakers.

I get the stigma of "cool companies" that have chefs that serve organic meals 4 times a day, but are those benefits really all that superficial? As a new graduate who has to move to likely a very expensive part of the US to work for them, making the transition easier by eliminating some worries from my life (like doing lots and lots of grocery shopping) is a pretty nice benefit.

For one, it's heavy compared to some very simple JS and a good portion of the time you don't need the entirety of the library.

That said, it does abstract much of the crap that goes along with XMLHttpRequests and all the cross-browser idiosyncrasies that go along with it.

I'd say at this point it's a matter of personal preference and performance requirements.