4
points
danneu
Joined 1,932 karma
- 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
- Location: Guadalajara (US citizen)
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
- SEEKING WORK | US citizen | Remote only (or Guadalajara)
Tech: 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 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
- Location: Austin, TX
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.
- Location: Home base in Austin, TX b
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.
- 22 points
- Years ago, I played with the idea: https://github.com/danneu/klobb
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.
- Wow, that's great.
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.
- Exactly. I thought it was a great speed, and there really aren't many slow-spanish resources online which makes it hard to transcend intermediate hell.
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.
- I started building a lil thing inspired by Continuum: https://github.com/danneu/p2-space-arena
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.
- I'm really rusty, but if I can recall the simplest example correctly, you can't just naively go from this Kotlin code:
to this Java code:Server { req -> Response().html("<h1>Hello world</h1>") }
Because Server is implemented in Kotlin and the Java lambda certainly isn't a kotlin.Function.new Server(req -> new Response().html("<h1>Hello world</h1>")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.
- Good job reaching a stable release.
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<Response>` 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
- Elm's JSON combinators are great.
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.
- At the same time, requiring better passwords is an anti-spam mechanism for the platform.
I once registered a Reddit account that had the same password as its username. After my first post, the account's password was changed and it started posting spam.
The only explanation I have is that someone was crawling the latest posts and trying to crack new accounts so that they have a legit first post and registration IP address to avoid auto-moderation.
Or, for example, a forum that drops all rate-limits once you are 1 year old with 1,000 posts. It now may be attractive to crack trusted accounts so that you can send mass PM spam. Or imagine if a moderator gets their password cracked.
So it's not necessarily just in the best interest of the platform, but also everyone that uses the platform. Though that's no excuse for particularly annoying password requirements.
- I agree that Node once felt tangibly worse. I used Clojure for three years to avoid Node until I had to use Node at work (nobody was going to learn Clojure) and I discovered Koa when it just released.
Even back in Koa 1, co/yield/function* closed the gap for me. Nowadays it's much better with ubiquitous promise usage and async/await.
I miss various things about Clojure like the editor-as-a-repl development cycle, but in my opinion, they still amount to small technical differences that play second fiddle to business concerns.
- I haven't used it, but it's still the same pseudocode:
For CRUD, I'm not too convinced it's much different than what you'd be doing anywhere else.defmodule HelloPhoenix.UserController do def index(conn, _params) do users = HelloPhoenix.Repo.all(HelloPhoenixUser) render conn, "index.json", users: users end endFor websockets, streaming, and other stuff beyond request -> database query -> response, then competing abstractions get more interesting.
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