Hacker Newsnew | comments | show | ask | jobs | submit | skrebbel's comments login

Klets (https://klets.com) | Eindhoven, the Netherlands, Customer Support & Happiness | INTERN, ONSITE

At Klets we bring customer chat to all businesses in the world. We believe that chat is a great communication medium but it's underused for communication between companies and their customers. Especially B2B companies nearly exclusively use phone and email, and this is simply because there have been no good chat-based solutions to fill this gap. Klets fixes this. We launched a month ago and are seeing impressive traction and adoption.

We're looking for an intern who wants to make our existing and potential customers extremely happy. Your role will be very flexible and very much open to your own wishes and (study) needs. It's a plus if you have a clue about online marketing and can write (blog) well. You'll be studying something related to marketing, business or communication right now, and we'll tune the opening to match your studies. The fact that you, a non-programmer, are looking on Hacker News for internships gives you an immediate edge.

Most of our customer support (obviously) goes over chat, so it's important that you enjoy chat and text messaging. We find that customer support via Klets makes complete strangers have fun and crack jokes with you, so it's certainly a fun job. We'd also love for you to contribute to our marketing strategy if that's up your alley - content marketing, growth hacks - anything you can think of, really.

We'd like you to live relatively nearby but we're open to a big part of your work to take place remotely if necessary. So if you're in (or near) the Netherlands but not near Eindhoven, no biggie, with a combination of trains and remote work we'll make things work just fine.

We're a very young startup, and in our stage, there is no real difference between sales and customer support, and even marketing (because a great product with great support tends to market itself to some extent). If you're looking for a place to really significantly contribute to a startup's growth, get in touch.

Interested? Chat with us on https://klets.com/klets (no login or signup needed)

(we're not interested in recruiters and intermediaries - please don't get in touch)

How often do you do async stuff per millisecond that this starts to matter? At least for browser stuff I really don't see the problem.

The problem usually arises when the GC pressure introduced from the promises (often the intermediate promises) created by many active/concurrent tasks starts burning copious amounts of cycles.

As your concurrency increases, a poor promise implementation starts burning copious amount of valuable cycles, often largely due to GC pressure.

In the abstract this doesn't sound that bad, but when comparing well behaved implementations such as BlueBird, RSVP, When, ES6-Promise etc. with the current state, (July 3, 2015) native Promises, the difference is still staggering.

As for the browser, a promise is a great way to handle async and often a great abstraction around a single potentially remote entity. As more ambitious applications are created, it isn't uncommon to have thousands or tens of thousands of these remote entities. Wouldn't it be nice, if the overhead of using the promise was negligible?

I've worked on node.js projects where certain promises implementations were too slow for the use-case

Use loose mode. Not only will sane code seldom hit the edge cases, it also generates way more readable es5. And, according to this article, there's hardly any performance hit left.

we looked at what you can do with a ref to a DOM component and realized that the only useful thing you can do with it is call this.refs.giraffe.getDOMNode() to get the underlying DOM node. In this release, this.refs.giraffe is the actual DOM node.

This only holds if you use Facebook's particular flavour of Flux, I guess.

Personally, I use refs a lot to bubble events down the component hierarchy. For example, when the browser window loses focus and gains it again, some sub sub component of the root component might want to do set some local state. Whatever, display a "welcome back!" message or something. I can use refs to do this.refs.subcomponent.onWindowShow() and this makes my code very clean and flexible - it keeps browser event stuff out of my flux stores, and only the actual important user data in there.

Similarly, I use refs to ask an <Input> component whether its value is valid according to some validation rule. I could also give the Input an onValueValidityChanged prop, but that just increases the amount of bookkeeping I need to do. If I'm rendering a form with 2 inputs, name and email, calling "this.refs.name.isValid()" in some onButtonClick handler makes a lot of sense to me.

I really liked how React was separated from particular architecture patterns, but this change makes that a lot more difficult. I really hope this change can still be reversed.

This is only true for DOM components, e.g. an <input> component, which can't have a onWindowShow() method associated with it.

Customer components, e.g. an <MyInput> component that wraps a DOM <input> and provides custom onWindowShow() functionality are unaffected.

Ahhhh of course! OK that makes a lot of sense. Actually, it makes is more uniform: a ref has whatever properties and methods that ref could possibly expose - be it a "built-in" component (aka a DOM element) or a custom one. Nice!

Personally, I use refs a lot to bubble events down the component hierarchy. For example, when the browser window loses focus and gains it again, some sub sub component of the root component might want to do set some local state. Whatever, display a "welcome back!" message or something

Isn't that a bit of an antipattern? It seems that sending events down the hierarchy is something that React goes out of its way to make awkward, and on purpose.

In the case you've given, I'm not clear why you wouldn't just bind to the window's focus and blur events from within componentWillMount, anyway.

I'm not sure that it is an antipattern. Personally, I feel that attaching event handlers to global window events from all over the place is just as bad, basically a singleton in disguise.

Another use case that I came across was where we wanted a search dropdown to open in the header when a user clicked somewhere in the middle of the page content. One option would be to make a PageStateStore and add an isSearchDropdownVisible to it, but I don't like doing flux that way because I don't want UI details to be part of my model later.

I think having isVisible in the SearchDropdown state is much more elegant, but that poses the slight problem of how to change that state from the other side of the page. We did that by having the item in the page have an onWantToSearch event, which the page had a handler for that invoked this.refs.header.showSearch(), which in turn invoked this.refs.searchDropdown.setVisible(true), which did a simple this.setState({isVisible: true}).

So, in general, the event first bubbles all up the tree (through custom react onSomething, onSomethingElse props), and then bubbles down the tree (through method calls on refs). This exposes a really elegant design, because it made the Header component be "a thing that allows searching" (because it has a showSearch() method), and the page item an "a thing that allows a user to initiate a search action" (because it has a onWantToSearch event). The available methods and onSomething props of all components perfectly matched the possible behaviors of the components, and no behaviour is "hidden" inside a singleton mesh of flux stores.

Props are awkward on purpose but not to discourage their use, they're awkward so you're explicit about how you're modeling your data and how your data flows through your app/component tree.

You can cleanly implement that "welcome back!" example using flux actions and stores, without having to bubble down events.

You must have misread the blog post. This change only affects DOM components like <div />, not composites like your <Input />. I wrote in the post:

References to custom component classes work exactly as before.

Yep, I'm blind :-) Thanks!

I'm a bit confused. Are agencies startups too now?

The team who was recruited had to work as typical government contractors but are now forming their own company which they want to operate differently from all the other companies that build stuff for the government. One of the team members told me a while ago they were interested in organizing into a public benefit corporation or something like that (I had never heard of such a thing).

Hi Stephen! Which one of us did you talk to? We did just incorporate as a public benefit corporation. It's basically a for-profit corporation that also has a social mission baked into the charter.

Nice! Feature request: Use replaceState so I don't need to hit back seventy times when I'm done reading slides on the internet.

This, so very necessary. It's the one major qualm I have with many JS slide show packages.

Done & Pushed. Great call guys.

nice turn around time!

awesome! works like a charm :)

Good call

Every Windows developer who has git also has bash installed. Because of that, most simple .sh build scripts tend to work fine on Windows these days.

Pure guess: they were already driving the plane to the runway while people were still getting settled, and similarly they'd take people's luggage down while navigating to the airport. These days, I assume there are regulations that disallow anybody to move until the plane is at a full standstill.

I wonder why, though. Seems to me like an airplane on the ground is a lot safer to stand in than a fully packed bus in a busy city. Any ideas?

My first thought: you would not want luggage blocking aisles if there's an accident on the ground.

Also, aircraft (and trains) are held to a far greater safety standard. Yesterday's bus crash [1] is unlikely to have much investigation, never mind a change to driving practices, road engineering, law enforcement, or anything else.

[1] http://www.theguardian.com/world/2015/jun/28/belgium-coach-c...

You have to wonder how such a crash can happen on clear, dry open roads in good weather. Buses never travel that fast, nor will they have reckless drivers. There's a slight irony in that the coach is made by Van Hool which is a Belgian company - and make very good coaches from what I know.

Belgium has a slightly mad thing that they allow buses full of people without seat belts / standing to travel at 50 mph along the motorways.

>> "Belgium has a slightly mad thing that they allow buses full of people without seat belts / standing to travel at 50 mph along the motorways."

I don't think that's specific to Belgium. Even when I was travelling to high school in the UK 8 years ago they would account for standing room when deciding how many buses were required. So you had a bus full of kids all seated and then standing from the front to the back without room to move and the bus going as fast as 60mph. I never really thought of the safety implications but looking back it seems very stupid.

Same as back in Hungary, travelling between my home town and university (2h bus ride), and often people were spilling over all the way to the lower steps inside of the door (that means carrying people almost at 2x seat capacity)... Just crazy...

> Seems to me like an airplane on the ground is a lot safer to stand in than a fully packed bus in a busy city. Any ideas?

A plane is designed to fly sitting passengers, a city bus is designed to drive standing passengers. A driving plane has very poor suspension - it's bumpy and the bumps are leveraged by the tall landing gears. Inside the plane, people won't just be standing, they will be unpacking the overhead lockers, handing around heavy luggage over people's heads. Busses don't have overhead storage for heavy items, probably for this exact reason.

The scale difference in airplanes can be massive. see accidents like https://www.youtube.com/watch?v=6Yx7aNdGYZo

Seriously? You'd take a job that requires that you lie about your personal life?

I wouldn't defend hiring based on hobbies, but it's pretty easy to make a comment like "I really like X, but these days I mostly do stuff with my family..." and it's a lot more human sounding than "I have no hobbies."

Agreed on your incredulity. I've never understood ethics behind such type of advice.

File it under Dale Carnegie's "How to win friends and influence people".

If there could ever be a treatise on psychopathy, that'd be it.

No job requires you to lie about your personal life, but if they're willing to give you credit for a lie that doesn't matter at all - why the hell not?

Although having said that, judging you so much on your "fit" is a pretty big red flag.

It may not matter to them at all, but shouldn't it matter to you?

With this stance, you and the OP are uncompromising on this issue which can be viewed as good or bad depending on context but I think in this case it's very unfavorable.

Everyone has hobbies just take the time to think about it and you will come up with something better than "none" which is not really exciting to hear and might send the wrong signal to the recruiter that you are not interested enough in the opening position.

I like the idea, it's a bit like how lazy list processing works, but then applied to promises.

However, I don't completely see the appeal as soon as ES6 or ES7 transforms with a tool like Babel are ok for you. ES7 is probably going to have C#-like async/await syntax[0], which takes this problem away entirely and in a much less complicated matter. This syntax works great today with babeljs. And even if you don't dare using experimental ES7 features yet, you can accomplish just about exactly the same with ES6 generators[1].

If you really really need to avoid compiling your code, then I can see the appeal of this "pseudosynchronous" idea, but I do feel that it's much more complex and error prone than setting up a build process instead.

[0] https://github.com/lukehoban/ecmascript-asyncawait [1] http://davidwalsh.name/async-generators


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact