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