joneil

I never realised this - thanks!

It feels like by adding styling I could make those who click on the “feed” link, but don’t yet know what RSS is have a much better experience than seeing unstyled XML and being confused.

The class name on the HTML element definitely makes me want to start using more expressive class names in my code. (Doesn't seem I'm able to copy/paste it into a Hacker News comment)

I have a blog with two main categories that are pretty separate:

https://jasono.co/blog/software-engineering/ - mostly focused on front end, and a lot of older posts about the Haxe programming language.

https://jasono.co/blog/personal/ - mostly about faith (I consider myself both Christian and Agnostic)

They were considered, I was on the team that considered them. (I work at Culture Amp and at one point was leading the Design System team).

To be clear: embedding Elm in React is easy (we host the main NPM library for doing so: https://github.com/cultureamp/react-elm-components). But embedding React in Elm is harder, as Elm doesn't give any easy "escape hatches" to interact with native JS code.

The main opportunity is to use Web Components. Elm knows how to render any HTML component, including `x-my-custom-button`, which could render using React or something else. We looked into options for this, including prototyping https://www.npmjs.com/package/backstitch as a way to embed our React components as Web Components for consumption in Elm. (No open source packages existed to do this at the time).

We also did quite a deep dive on using Stencil, which has a React-like API, to create web components for both React and Elm - even including publishing new plugins for the ecosystem to generate Elm bindings for your web components. Kevin went into some of the detail for this in the post if you're interested.

I work at Culture Amp and was once team lead of the Design System team.

Its not hard to justify the team. If 4 front end engineers in a design system team can solve some common problems (writing components, improving accessibility of existing components, writing docs, answering technical questions etc) in a way that makes 40 product facing front end engineers more effective than 44 who don't have access to the team... then the team is a net positive.

At our scale we'd need to give a 10% improvement in efficiency to the product engineers. Both the engineers in product teams, and the various levels of leadership, have seen enough to believe we're making at least that much of a difference. Like almost any other company... measuring that accurately is a nightmare (and would require a significantly larger team just to measure ) but its a safe enough bet that we continue to invest in it.

(I'm a front end engineer at Culture Amp, and have been involved in hiring)

Perhaps the wording in the blog post is too strong, because people in this thread seem to be interpreting it as a hard rule. The wording was:

> When someone tells us in an interview they’re excited about working here because they like functional programming (say), we count that as an indication they might not be a good fit.

When we do interviewers each person fills out a scorecard for the candidate with several criteria: things like technical skills, communication, UX thinking, interest in the company product/mission, etc.

Under "technical skills" I would usually have counted interest in Elm as a positive, as long as they weren't expecting to only write it. As I mentioned elsewhere in the thread, they'd also be likely to be contributing to Ruby on Rails codebases... so they better be open to, and maybe even excited by, different paradigms, because that's going to be part of the job.

(I work at Culture Amp)

In our interviews one of the things we look for is people who care about our mission (improving workplace cultures, basically). Its not a requirement but it is one of the factors when it comes to making a decision, particularly if we have more qualified candidates than roles.

> If someone came excited about Elm _and_ was interested in the company's product that was fine.

I'd even say if someone is excited about Elm _and_ was interested in making a great quality product (great UX, accessible, performant, maintainable etc.) that would also be a good fit.

I also mentioned above that the engineers we hired to work on features that happened to have Elm front ends would have been working on Ruby on Rails backends most of the time, and we generally expected engineers to be willing to jump into both sides of the stack, even if they specialised in one or the other. A person who is really excited about functional programming and joining only for the chance to work in functional programming languages might end up grating against working in a rails codebase. That's the sort of practical thing we were trying to avoid. (The same would be true today for candidates who are super excited about TS / React / Next.js - they're still going to be expected to occasionally jump into whatever backend stack their team is using).

I work at Culture Amp and have been involved in hiring decisions, including for people who were excited about Elm so happy to comment here. As others have guessed, this is an "indication" not a "rule", and it was more about people who were applying _only_ because of the tech stack, rather than a sense of wanting to build a quality product, or alignment to the company's mission (improving workplace cultures). We hired plenty of people who mentioned Elm. I mentioned Elm in my interview.

Part of the reason for this is very pragmatic: during the time when Elm was in common use at Culture Amp, almost all of the APIs that Elm would have been talking to were written in Ruby on Rails, and our engineers were expected to be able to contribute to work that required changes in both the Elm front end and the Rails API. If someone was a functional language purist, and only wanted to work in say Haskell on the backend... then they wouldn't enjoy being on one of our product teams where writing Ruby on Rails code was part of the day-to-day.

As an engineer at Culture Amp, I strongly agree with all of this, especially:

> Actually improving employee engagement is far from solved or commoditised, and I believe that anyone that can bring an original idea that can be proven to lead to real-world change can still find a place in this industry.

OP it sounds like you and your co-founder had good intuition and insights into what the industry needs. But as indeed30 mentions the market is mature, the competition is strong, the expectations of quality and a certain feature breadth are high, and you'd probably need some decent sales skills to get a look in.

Well done on picking a good problem and giving it a shot. As someone who failed a startup at a similar stage, it sounds like you've walked away at a good time, learned good lessons, and hopefully you've got good opportunities ahead.

That was a helpful read, thanks. My company (also in Melbourne!) is probably one stage of growth beneath this. We have “verticals” and “teams” but don’t really have the layer in the middle yet (“domains”).

As we’ve grown from only a few teams, to multiple verticals, we’ve tried to jump straight from unclear boundaries and implicit APIs to fully versioned services and packages.

Thinking about these as solutions to communication problems, where the problems differ in degree depending on the number of teams interacting with it, is a useful way of framing the discussions.

Hopefully it brings some clarity to discussions about when the light-and-loose methods are okay, and when the more heavy processes are justified.

Oh I’ve got to give that a go!

I used Haxe full time for several years for web development (even started a startup with it!)

It predated Typescript, so at the time the killer feature was being able to write type-safe JavaScript, and being able to share code with a backend which is potentially another language (like PHP).

These days I’m at a company with a lot of TS, and too many other languages (Elm, Ruby, Kotlin, Elixir...) so we’re not looking to add something like Haxe, but I often still miss the expressive type system, the really nice language server integrations, having the multiple output targets so it’s the same language everywhere, and the type safe macro system.

So I often use Haxe for hobby projects still, but then I miss things from the JS ecosystem. You have access to NPM but there’s no equivalent project to DefinitelyTyped. Some of the tools integrate well (webpack as an example), some don’t (Jest). React works, but the way JSX works doesn’t integrate as nicely with the language server. Etc

I also missed some modern es6 syntax. Haxe finally got arrow functions in v4. The thing I’m excited by in this release is module level fields - previously everything had to be in a class, now they don’t. Haxe was already good for writing functional style code. Now when you read the source code it’ll look like it and not have the “class” keyword when you don’t need it.

Browser vendors are finally catching on.

From Firefox 72 permission prompts won’t be shown unless they’re triggered from a user interaction.

From the blog post:

> Notification prompts are very unpopular. On Release, about 99% of notification prompts go unaccepted, with 48% being actively denied by the user.

https://blog.mozilla.org/futurereleases/2019/11/04/restricti...

I’ve heard Chrome is moving in a similar direction

I can read it just fine from here (Telstra 4G)

One possible approach is talked about in the latest Elm-town podcast: https://elmtown.audio/the-risk-of-elm-dhruv-dang

Amazing work! I'll be following along keenly... and glad to know there's an exhaustive approach being taken to figuring out if anything else was affected

It's our version of sports teams. ("Cavs are better than 76ers!")

We pick a tribe and can be loud and obnoxious in support of them.

I’ve used it for web (my failed startup was in Haxe, my side projects still are mostly Haxe).

To be honest these days I mostly just use it as a “better JavaScript” because I’d prefer my backend to be NodeJS rather than PHP or Java or sone other Haxe target. But I really do prefer it to JavaScript, even with Babel and Flow and ES6 and all the things to modernise Js.

One advantage Python might have is that the dependencies you use are human readable, they're not compiled, minified or obfuscated. This in theory would make auditing dependencies easier, but I imagine 99% of the time people aren't thoroughly auditing.

The “containers” thing they’re doing to have separate containers with separate cookie jars, is something I’m loving that some die hard Chrome fans have said “I want that” when I explain it to them.

It allows me to have a work container logged in to work trello and Gmail, and a personal container logged in to personal trello and Gmail. It also allows me to have a FB container so I can stay logged in there, but do all my browsing in other containers so they don’t know which other sites I’ve been visiting. That’s a feature I didn’t know I wanted until they built it.

If you're reading HN as a 16 year old I like the chances that you'll be entrepreneurial enough to make your own way even in a bad economy. Either just finding the opportunities locally, or creating things for a global market, or packing a bag and going somewhere more promising. If you're willing to keep growing / hacking / changing, and especially if you have tech skills, you'll probably do a lot better in a downturn than much of the rest of the country.

As an Aussie, a very confronting read. You're kind of aware of various problems brewing on the horizon, that China's demand for iron ore is low, that our housing costs are too high, and therefore mortgages / household debt are too high, all of this. But then when you weigh it all up the feeling of being in trouble is very real, and we've had 6 years of flaky leadership that's too worried about political maneuvers to worry about these structural problems.

There are some things that give me hope though. We've built a number of great marketplace startups, including Freelancer (where the author works), Envato, 99 designs etc. So that's a strength, and the tech scene in general has grown massively in the last 5 years. Our mining industry might be in the slumps but we pioneered some pretty great drone tech, self-driving tech, and remote operations stuff. And if you get creative with remote work and global teams, the timezones we're in can be seen as strategic assets.

There are smart people here. But like most other liberal democracies, we're really divided and have a large voting block that just wants to keep the status quo and isn't being honest about the challenges. But hey, we just voted yes to marriage equality so the electorate has some hope left.

This is my first attempt at using D3 for anything more than a simple bar chart. I wanted to do a visualization that gave a sense of on what issues the community was united or divided. I also wanted to show not just which side of an issue people chose, but how much they cared.

Feedback welcome!

Credit to Lars Doucet [1] who ran the survey - his results were published on PC Gamer earlier today [2].

[1]: https://twitter.com/larsiusprime/ [2]: http://www.pcgamer.com/the-biggest-issues-with-steam-in-2017...

The candidate wouldn't need to give a fake inflated salary... the company isn't allowed to ask about salary history at all.

Even if they weren't, I don't see any real trouble with your scenario (other than that I think establishing a pattern of lying in a relationship so early probably isn't great). But if my last job underpaid me, and now I want to earn market rate... I'd be grateful to not have to answer questions about my previous salary.

It does have built in type definitions for React, where as all other libraries you probably need to use flow-typed (similar to definitely-typed in TypeScript).

So it does kind of have React integration, but it's pretty loose - you can use it with any other framework, and there's nothing obviously React-specific about the language.

Edit: See https://flow.org/en/docs/react/types/

Krista Tippett (from the "On Being" podcast) talks about this as one of the most important social tasks at the moment - to help calm fears of those around us so that as a society we're less fearful of each other, and more open to each other. I found it a fascinating call-to-action, as the rise of fear is something I feel like I've been noticing.

Having said that, I'm only 30, so don't know if the local pattern of rising fear is part of a larger story of less fear (compared to cold war days, for example).

I'm the same. Been using since Phoenix 0.3 and am stoked about these changes, and the thought that Rust, and the major perf and safety improvements that come with it, are beginning to find their way into Gecko. Amazing work from a team that many had dismissed as irrelevant.

Prove them wrong!

This is an interesting way to encourage people to contribute to Wikipedia. The "get out and explore your city" motivation reminds me of Pokemon Go... but this time you're sharing what you find with the world via Wikipedia.

In my immediate area (Williamstown - a suburb of Melbourne) the only monuments listed are train stations, but once you get into the city it looks more interesting.

One suggestion - add a big tagline at the top of the page. If I scroll down and read the text I understand what is going on, but it would be great to make it obvious right up front. "Explore monuments in your city and share your photos on Wikipedia".

[edit] it's not very usable on my phone - I can use a map but when I click an icon it opens a list that is off to the right of the screen, and I can't scroll to it. A mobile first interface would be ideal for getting me to go out and participate. A big "monuments near me" button that opens the map to my current location, and then the ability to take a photo from my camera. Should be a pretty easy fix/feature that would make this way more spontaneous and fun to use when on a phone.

I just confirmed this is working with iiNet (2nd or 3rd biggest broadband provider in Aus).

The block screen looks like this:

http://i.imgur.com/Tuz7KrZ.jpg

So it is being blocked at ISP level, and it's up to them how they implement the block. For now, they've chosen DNS blocking, which is of course easy to work around.

Here's hoping the block encourages everyday citizens to be take technical measures to evade not just the block but the censorship.

Does Semver's spec take into account integer overflows?