dansingerman

You’re right. I wasn’t aware of word-in-one and it’s a similar idea. The closest I’ve seen to my game in fact. ( when I had the idea for it I wondered if anyone else had had the same idea. I’ve not seen another game doing exactly the same yet)

I’ve made it so it only shows the share button if the browser supports native sharing (navigator.share) - wordle just copies it to the clipboard on other browsers, which I found a little naff so that I didn’t really bother to do that.

Only showing the right/wrong is how it’s supposed to work. I thought about it sharing the grid like wordle, but I thought that was too much of a copy, and unlike wordle I think the wordall grid doesn’t contain as much meaning (it contains some, but I am not sure what it conveys is that interesting)

Really appreciate your interest - I’m glad you like it!

There seems a weird caching issue that I think I’ve fixed. Can you try again?

Thanks - it is behind cloudflare, and there does seem to be the odd caching issue where there is a mismatch between the files. I'll look further into it.

Thanks for the kind comment. The dark mode is on the dev plan, I just didn’t have it ready for launch.

Yes - it probably is a bit harder than Wordle. I think this is for people who like Wordle, but find it a bit too easy.

Thank you!

Thanks - I will check that out

Ever since I became aware of Wordle (and its success) I’ve wanted to make my own daily word game. This is unashamedly inspired by Wordle, but unlike most Wordle derivatives it’s fundamentally a different game with a different game mechanism. It deliberately looks a bit like Wordle, as it is mainly aimed at people who currently play Wordle (I understand there’s a lot of them), but might want a bit more of a challenge. If you try it I hope you like it.

Totally agreed; in general the advice a VC will give you will be what they consider you need to do for them to be interested in investing in you.

This is not the same as ‘good’ advice, and will often be diametrically opposed to it.

I'm guessing this only affected Android devices? But did those devices have the "Allow apps from unknown sources" option checked?

I feel like there's some pretty pertinent technical details missing from the story.

(Or am I missing something?)

This is a great comment.

Imagine the investment that would suddenly start in accessibility if Google publicly announced it was an important part of search engine rankings.

Goodhart's Law? https://en.wikipedia.org/wiki/Goodhart%27s_law

TLDR: You don't need to manage state in the client now; manage state in the server by making more API requests. And GraphQL makes that a bit easier. Oh and you still need to manage state in the client.

> That one definitely sounds true to me, the complexity of modern software definitely makes it harder to be competitive with big shops.

I disagree. If you want to make a competitive product to the products made by big shops, then that is true. However true innovation is often making something in a category that is new or not well served.

When Jobs/Wozniak made the Apple 1, they weren't competing with big shops mass producing other desktops, they were competing with the likes of MITS producing build-your-own computer kits.

Also the prevalence of on-demand services and APIs now mean you rarely have to make lots of complex software from the ground up. The secret is to find some value your software can deliver which competitors don't exist for, or don't do well.

If you look at the boom in solopreneurship and side projects it's self-evident to me it's never been easier.

Aside: the reason the 'cool hack' stories don't exist now is that they were often about using limited resources to do things that were seemingly difficult/impossible on the available platforms. So they were still examples of new software delivering value. But now as we are far less resource-constrained, and software as a whole is a lot more mature, these opportunities are a lot more scarce.

I've used slim too. I have the same opinion of it as Haml.

Agreed! If I need to debug it in chrome inspector (or similar) I don't like to have to think in terms of the abstraction I'm using to get the result I want.

Web development is complex enough (server side, js, css) without adding an abstraction layer to your markup too.

I know I'm very likely to be in a minority here, but I hate both Haml and Markdown.

I much prefer HTML and erb.

You say 'only millions records'. Even if you had 2^36 records (that's over 68 billion) the chances of a collision should be 0.0000000000000004

That really is vanishingly small.

So, rationally, I'd guess it is more likely there is a problem with the implementation of UUID you are using, or just perhaps there is some other cause of the collision...like a bug?

That is likely due to a fault in the UUID generator, rather than the concept of using UUIDs.

http://www.h2database.com/html/advanced.html#uuid

Do you worry about the irrational fear that one day all the oxygen molecules in the room will gather in an upper corner, and you'll suffocate?

This is so useful I've knocked up a quick gem to wrap the range service (i.e. it only transmits the first 5 chars of the SHA1 hash)

https://github.com/dansingerman/pwned_passwords_v2

The code is left deliberately simple so eyeballing lets you know it's not doing anything hinky with the passwords.

"Single Page Apps increase the amount of client side logic and user input processing. This makes them more likely to be vulnerable to DOM-based XSS, which, as previously mentioned, is very difficult for website owners to detect."

Hmmm...assuming your back end has all the requisite validation and other security in place, how can a SPA cause an XSS? Are there any purely client side attack vectors (XSS or otherwise) that need to be considered if your back end is fully protected?

The rate limiting was done by the application server, but was completely separate from the varnish layer. (I think it was something fairly naive to do with memcached, but that's not terribly important). What was important was that the application server could serve the 400* with an expiry, and varnish would deal with that load until the expiry.

*This was 2011. The 429 response code wasn't defined until 2012.

The code examples are written in ruby and lua - I take it that in your live environment you use the lua script compiled into nginx?

Does this mean every rate limited request is hitting redis?

I had this problem years ago, and I used varnish to offload the rate limited traffic, which scaled very well then. Here is a blog post I wrote about it: http://blog.dansingerman.com/post/4604532761/how-to-block-ra...

(it was written directly in response to a 'One of your users has a misbehaving script which is accidentally sending you a lot of requests' issue)

I know the song well, but it's the first time I've really read the lyrics and ... wow... (running my own business with 3 small children, one a son)... listening to it on Spotify now.

Exactly. It's not like performance is or is not important. It's about the trade-off given the detail and the context.

Not convinced either way whether having the same interface for all of the stack is a good idea or not, but it did remind me of Joel Spolsky's blog post on leaky abstractions http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...

My take away from this is you need to ask 'why' as often as 'what' and 'how' when developing software.

In my experience many software developers completely fail to challenge the 'why' of what they're being asked to do, and jump right to design/coding.

To be fair though, not all software developers work in an environment where they can, or feel they can, ask or challenge the 'why', but the software will only benefit if they do.

It's more then just that with heroku's random routing.

If you are on shared tenancy dynos, and your current configuration is nearing maximum capacity, then adding dynos can reduce performance. Not per dyno, but across the entire platform.

Counter-intuitive but true.