Comments URL: https://news.ycombinator.com/item?id=43764444

Points: 4

# Comments: 0

Location: I'm generally based in Austin but I'm currently living abroad (US citizen)

Remote: Yes

Willing to relocate: Yes, though remote work opportunities are my top priority at the moment.

Technologies: The past 5 years, I've mostly been working on server applications with Node + Postgres and web client applications with React or Elm. I've been the first hire of the largest bitcoin casino. I've built a popular forum from scratch. https://github.com/danneu

Email: danrodneu@gmail.com

Remote: Yes

Willing to relocate: Yes, though remote work opportunities are my top priority at the moment.

Technologies: The past 5 years, I've mostly been working on server applications with Node + Postgres and web client applications with React or Elm. I've been the first hire of the largest bitcoin casino. I've built a popular forum from scratch. https://github.com/danneu

Email: danrodneu@gmail.com

Remote: Yes

Willing to relocate: No

Technologies: The past 5 years, I've mostly been working on server applications with Node + Postgres and web client applications with React or Elm. I've been the first hire of the largest bitcoin casino. I've built a popular forum from scratch. https://github.com/danneu

Email: danrodneu@gmail.com

Tech: The past 5 years, I've mostly been working on server applications with Node + Postgres and web client applications with React or Elm.

https://github.com/danneu

I've been the first hire of the largest bitcoin casino. I've built a popular forum from scratch with Node. I'm open to short-term work and longer term work, part-time work and full-time work.

Just shoot me an email: danrodneu@gmail.com

Remote: Yes

Willing to relocate: No

Technologies: My github profile will show a breadth of tech. Day-to-day over the last couple years I've mainly used Node, Postgres, React, and Elm.

Résumé/CV: Available upon request. https://github.com/danneu

Email: danrodneu@gmail.com

Two of the most interesting projects I've worked on over the last few years were a large open-source forum I built from scratch with 1000s of logins per day and the work I've done for some of the largest projects in bitcoin gambling. Feel free to ask.

Remote: Yes, preferred

Willing to relocate: Possibly

Technologies: The main day-to-day production user-facing systems I've worked on in the last few years involve Javascript, Node.js, Express/Koa, Postgres, React, AWS, Websockets, Elm. My Github profile showcases a productive grasp of a lot more technologies.

Résumé/CV: Available upon request. https://github.com/danneu

Email: danrodneu@gmail.com

If there's one thing that best demonstrates my breadth of ability, it's that I built an open-source message board from scratch, myself, for an active community with Node + Postgres in my free-time over the years that gets thousands of registered logins per day.

While my resume will reveal my experience doing this repeatedly on team/co-founded projects, my solo forum project best shows all of the hats I can wear (from technical skills to soft skills) and my ability to execute in such an open-ended environment to ensure that I'm not just shipping code, but shipping a product that users like.

Comments URL: https://news.ycombinator.com/item?id=17903762

Points: 22

# Comments: 1

I went on to implement it in Swift (https://github.com/danneu/hansel) and then seriously improved on it in Kotlin (https://github.com/danneu/kog).

It was fun but hard to really make a convincing upgrade to Koa once you consider the rest of the ecosystem. For example, since Koa exposes Node's req/res, then you can still use existing Node/Express middleware.

Here's my attempt at building something for language learning since my listening skills trail so far behind my reading skills: https://www.danneu.com/slow-spanish/

It parses this painstakingly created file: https://github.com/danneu/slow-spanish/blob/a455da3a230632c2...

Unfortunately it's really hard to generate the source material (timestamping a transcript).

So my idea was to upload some slow-speaking audio to Youtube and let it autogen its .srt subtitle files. The subtitles don't come out perfectly, but it's the timestamp data I'm after since the goal is a UI that makes it easy to replay and scrub around spoken audio.

The English sections work well to give you context for the Spanish sections. Losing track of context is definitely one of the hardest parts of listening to a different language. "Wait, I thought we were still talking about his aunt." The English also makes it more of a leisurely exposure.

Another issue I have with most resources is that there's no way to easily replay chunks of audio. I'd prefer to be able to listen to bite-sized chunks until I understand them. I built https://www.danneu.com/slow-spanish/ (the three lil pigs) to prototype an idea where you listen to a story and can prev/next/replay any sentence.

Never did much game dev before but it gave me a lot of respect for people who can build one. It would probably take me a year just to figure out lag compensation.

But there are Kotlin features that don't map like type-safe @Dsl's which puts you in a position where you have to make concessions for interop.

What I found is that it's the other direction that takes some thought. For example, my Kotlin library needs more help than just @Jvm annotations to be usable from Java.

    Server { req -> Response().html("
Hello world
") }

    new Server(req -> new Response().html("
Hello world
") 

If that's a bad example (foggy memory), another one would be the use of @DslMarker or reflection to build my type-safe router: https://github.com/danneu/kog#type-safe-routing. Or how about inline functions with reified generics.

Kotlin does have Kotlin->Jvm interop annotations, but my take-away was that you would have to put some thought into your API and possibly make concessions so that you could sufficiently annotate it to the point that it's pleasant to use from Java. Not everything maps.

For example, you can see that OP went the route of using Java at the interface edges yet Kotlin internally to solve interop for their project.

I admit that "effectively one-way interop" is too heavy-handed of a statement, but there's definitely asymmetry that I ran into on my own project. For example, I would not recommend building something in Kotlin in the hopes that, once you're done, you can just sprinkle on some @Jvm annotations and end up with an API that's compelling to use from Java.

I have a Kotlin microframework that never made it past hobby-level stability[1].

One thing I found out is that you really have to write a library in Java if you want it to be used in both Java and Kotlin. Java -> Kotlin is effectively one-way interop.

I also found async programming to be really hard in Java which is why I wrapped Jetty. Meanwhile async APIs like Netty and Undertow were completely exotic to me.

For example, I couldn't figure out how to go from `Request -> Response` to `Request -> Promise` by wrapping Netty.

One thing I did find out was that Kotlin is probably my favorite language. Very similar to Swift, though I wish you could re-open 3rd party classes to make them conform to additional interfaces which you can do with Swift protocols.

I also never figured out how to hot reload code without restarting the server. Even JRebel didn't work for me. Looking at Jetbrains' own framework, their code that implements reloading is pretty intimidating[2].

OP is also the author of https://github.com/tipsy/j2html which I've been using in my own small servers. I couldn't figure out a better way to get typesafe html templating in the ecosystem.

[1]: https://github.com/danneu/kog [2]: http://ktor.io

That decision will probably save man-years of wasted time spent managing a trailing comma.

I'm sure one reason so many people have particular trouble with them is because, according to the survey, the vast majority of them come from a dynamically-typed language where you'd just go `user = JSON.parse(string)`.

I think a lot of people would be helped by tacking a bunch of real-world examples onto the actual Json.Decoder docs like how to decode `[1, [3, 5], 7, 9]` (nested range) into `[1, 3, 4, 5, 7, 9]`. One issue is that it's pretty hard to derive understanding from just function signatures, so a dozen quick-start / cookbook examples gives people something to chew on.

Combinators are really good at forbidding runtime errors which is a central theme of Elm, but it comes at the expense of a steeper learning curve than the weaker alternatives that come to mind: reflection and manual descent.