austinbirch's comments

Yeah, I can see that. Not disagreeing really.

I found ClojureScript worth it a few years ago. I’ve written two frontend apps (desktop-style interactive single-page applications meant for longer sessions) of reasonable size in ClojureScript. There’s a lot of non-glue code there (in fact mostly non-glue code, given the interactivity and statefulness of the applications).

Very little language and library churn has made maintaining them very straightforward really, and I won’t be rewriting them any time soon. Being able to use DataScript nearly made the choice worth it on it’s own!

The reason I’m mostly using TypeScript these days (for new things & backend code) is that it’s just too helpful for typing the data structures and reducing the "how many things do I have to keep in my head" burden. My TypeScript (like my ClojureScript) is mostly just functions and data structures (avoiding classes, inheritance, etc), and I avoid using any of the more complicated TypeScript features as much as possible.

It’s kind of heretical, but if Clojure had a well-adopted gradual structural type system (essentially what TypeScript has done for JavaScript) then I would find it hard to not pick Clojure for most things.

I can see why Clojure is seen that way ("advanced", "powerful"), but a big piece of it’s design is Rich Hickey’s view that "we can make the same software we're making today with dramatically simpler stuff."

Learning Clojure has made working in other languages much harder for me - pretty much all of my Clojure programming is functions plus transforming data structures (mostly maps). So few concepts to keep in your head!

The majority of my work is in TypeScript these days, and I always write the most Clojure-y TypeScript I can manage.

The rules engine direction is definitely an interesting one, hopefully there’s more exploration into that in the future.

For my needs now I actually wrote something pretty hacky[1] to get a 'reactive' version of DataScript’s Entity API.

As Nikita mentions in the article, I’ve found that most of the time I don’t really need queries in the UI, and so the entity API ends up fitting quite well – except that it’s non-reactive.

The `reactive-entity` library implements a reactive version of (most of?) the entity API, so you can pass entities in/through components, and then the components only re-render when the attributes accessed within those components change (including attributes accessed on other entities through refs).

Loads of room for improvement but I’ve used it successfully in a couple of projects.

[1]: https://github.com/austinbirch/reactive-entity

I have found this to be a good read[1]. Examples are in clojure but will apply to other dynamic languages with first-class functions etc.

[1]: http://mishadoff.com/blog/clojure-design-patterns/

A related talk, well worth watching: https://www.destroyallsoftware.com/talks/a-whole-new-world

Another vote for RHAs.

Not sure which model you have, but I have the MA750i. Really pleased with them.

Used to have VSonic GR07s, but the cable became broken. The build quality on the MA750i seems much better, so I’m not expecting the same outcome for these.

via https://www.designernews.co/stories/52617-john-cleese-on-how...

"Out of the Tar Pit" (Ben Moseley and Peter Marks) http://www.curtclifton.net/storage/papers/MoseleyMarks06a.pd...

Software complexity related to mutable state.

I would be interested, though probably not so much in the web UI for it - Emacs would be fine.

Jekyll, GitHub pages, and a custom domain.

Using Markdown means no constraint on what software you use to edit your posts, which is really nice.

Another advantage to using a static site generator is your blog will be (generally) fast to load, secure, and it will be really easy to find somewhere to host it for a low cost (or even for free).

I completely agree with this. I am working on a web application at the moment, and the server is very minimal. It just handles supplies a JSON-returning REST API, the index page, and some WebSockets stuff.

Doing things this way is quite nice, and forces separation between the client application and the server application. It makes the web application just a client, on an equal footing with any other client (iOS app, Android app, desktop application etc).

I had some success following this[1], though it didn’t seem to handle transferring lots of files at once very well.

[1]: http://www.webupd8.org/2013/01/upgrade-to-gvfs-with-mtp-supp...

I agree – anything from Rich Hickey. Especially "Persistent Data Structures"[1] and "Are We There Yet?"[2].

Though related to Clojure, they make you think about development in different ways.

[1]: http://www.infoq.com/presentations/Value-Identity-State-Rich...

[2]: http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic...

+1, I was just on my way to suggest this also.

Thanks a lot for the feedback, I really appreciate it.

I should have probably made it clear that this is really only a little side project, with the aim being to make back the small amount it costs me to run. Sorry for the confusion.

I wanted to differentiate it from Chess.com by making it simple, which is what I didn’t like about Chess.com. With that in mind, it is designed primarily for casual players.

I strongly agree with your thoughts on the signing up process, and I’ll definitely work on that.

Thanks again for your feedback, it's given me a lot to think about.

Austin

Thanks for the heads up on the security warning, I had a similar problem before and thought I fixed it. I'll look into it again.

I think making the whole player box a link would work great, so I'll get that done.

Thanks for your feedback, Austin.

I'm talking more about the branding, you shouldn't really have to debrand your OS to make it user friendly.

Not trying to be negative, as I haven't used elementary for any real amount of time yet, but: whenever I glance at the 'e' icon it reminds me of a negative action sign. Like a 'No right turn' road sign, or something similar. Not a problem once you're used to it, I suppose.

I'd quite like one too, thanks.

You should definitely check out Rework by 37signals. Although not in-depth, it definitely makes you think about the value of some of the more traditional notions.