andrejewski

This is really cool! I made a very similar game a couple years ago: https://jew.ski/prime-time/

It's interesting to compare the game play and design. My game is written in Elm and open source if anyone is interested. This website has keyboard inputs (y or n) which is a good idea. My game only does click/touch inputs.

Some feedback on the API design and README:

- Having a global registry of machines does not scale. Anyone building an app won't want to deal with the name conflicts. Having a `displayName` for debugging is fine but that's all. Having people pass the Machine instance to transitions directly is much more reliable/scalable.

- This [...rest] for event handlers is not good. Put those in a dedicated object because if you don't any new prop you add has the potential to break users. It's also bad because it looks like memory gets merged with those methods, making it likely the keys will conflict in view().

- Find a better name for T, it's confusing with Transition. Since it looks like a simple struct, maybe just have people pass {name, to} as plain data.

- You don't provide a rejected Promise example. I am interested how that works since it is something people tend to overlook.

- How the heck do I test my machines?

- A micro-framework that doesn't mention byte-size? Probably worth adding that statistic. My idea of a micro-framework is one that fits in a tweet.

- Write up how you expect this to be used. I don't think you could use this to build a real app because there's no way compose machines, only switch between them. You'd end up with huge machines because UIs are trees.

Happy to discuss more.

If anyone wants the Elm architecture in JavaScript there is Raj: https://jew.ski/raj/

I spent over a year building the framework and a set of libraries around it so that the architecture feels natural to JavaScript developers.

There's only a few of us building apps with it right now, but the stories for doing most anything are covered and as of 2 months ago the framework hit 1.0. It is a safe foundation to build on as I don't plan to ever change it.

Last winter I built an application called Subtweet that built on top of Twitter's Direct Message service, using Twitter's API as much as I could to reduce overhead. It is bittersweet that Twitter is improving DM as it makes Subtweet more and more unnecessary to users, but I am so happy to have all of these features built right in. I saw this shift coming when Twitter added multi-user DMing so I had already written the post mortem if anyone is interested.

http://subtweet.co/ http://chrisandrejewski.com/2015/02/07/subtweet-postmortem.h...

If anyone is interested in just scrapping links between webpages with JavaScript, I made Slinky (https://github.com/andrejewski/slinky). The API is simple and easily overridable.

Yes, the guarantees provided by true immutability are not met by "const". I wrote the note loosely using the author's expectations and advantages of immutability, not the exact definition. But thank you for letting me clarify.

Also I just noticed with Go's Unicode support we can write `const π = 3.14..` if we really wanted.

I am completely in support of Haskell and functional languages in general. There are some gaps in Go and definitely some glaring problems. But this comparison also only lists the bad. Go is good for what it was intended for which is concurrent programming and server/web application.

Just a note: I don't think it is fair to say Go has absolutely no immutability as it was defined, it does have "const". See http://golang.org/ref/spec#Constant_expressions

For people who have wanted to try this type of programming out but have not jumped the boat from JavaScript to ClojureScript, I created a little library that mixes Backbone and React in a similar model described in the article: https://github.com/andrejewski/reactbone

It takes away a lot of the data-binding cruft that you find in Backbone.View and works well with React without making you switch languages, design paradigms, or add new libraries. The Backbone component makes it easier to build data hierarchies than with plain JS, but I assume other MVC frameworks could be retrofitted to work with React.

These are some design resource pools I visit: http://www.awwwards.com/ (all website design) https://news.layervault.com/ (Site Designs) http://sidebar.io/ (UI+UX too)

This is not unprofessionalism; it is poor UX. The sensible backlash to the Nickelback feature is that is was set "by default," not that ripping on Nickelback is a humorous, widely accepted activity. This app could have retained that "cleverness" and "easter egg" vibe by keeping the setting but not having it be active by default. With proper UX considered, the backlash in this case could have been avoided.

I have a similar problem, but I'm off by a year. I'm fifteen and have basically run out of any CS-related classes to take at my school. I have shifted into math classes (Calc, Stats) to help me get some "computation" this year at school. Just as someone who was where you are, I'd say don't get discouraged by what your school offers and try to work on your craft outside of school. Depending on how much you have learned about CS and programming, maybe learning more and iterating on some side projects would suffice. It's definitely something that is hard to get over, you're not alone. Keep developing.

Now I'm really going to have to worry about leaving my account open on my devices. They didn't show it but these payments need some type of password protection.

I haven't been hit yet.

1. Care about the project. 2. Care about the users. Know what the user wants and what is in the best interest of the user. 3. Be able to defend yourself and our product in a battle royal (Accepted). 4. [Because there can be more] Help the technical co-founder anyway you can.

I know of Awwwards.com, but they cater to specifically advancements in the design aspects of the actual site and you have to pay for a submission. The usual go-around is to submit to HN, TechCrunch, maybe the Next Web or Engadget depending on your product. There are boards on Reddit and Digg that attract a similar audience to HN, so it really depends how you want to launch whatever it is you're working on. If you are looking for users I would not recommend coming to HN and similar for your audience, however if you are coming for criticism and maybe some (VC) capital, HN and those listed above can sure meet that goal.

[Edit] I found your site, cafecoders.us and would also recommend getting your SEO in place so it is easier to find you. I was using Google and your Whois lookup came before your actual site did. In fact, this submission is ranked higher. I like the idea and would be willing to help if you ever need it, http://bit.ly/MCnWmq (free).

Older IEs have Microsoft proprietary CSS jargon like filter that may work, but I don't know about transitions specifically.

I like how it is not best viewed in Internet Explorer!

I agree. As it stands now it would make the most sense to learn JavaScript, then I would learn jQuery if I were you, then move into sockets and node.js. You could then use this one language for the frontend and server-side.

Don't learn Java. The applet is dead. [Java Hate]

Instead of the image box with just a border, maybe have the image inside an image of the container it comes in.

It's definitely something that gave me an idea.

Ha.

I did this in two hours. If there are problems, I'm sorry. Please point them out by replying here.

Very interesting and a bit scary. Think about it, a screen that can reach out and change its shape. That almost guarantees some (software) application misuse if they are given access to screen control. But on the other hand, gaming would be more interesting with something more to interact with than just what is displayed on screen.

It will be interesting to see what becomes of this.

This seems like a walled garden approach, a better strategy may be a community where people can vote on names publicly. There's potential here, but more if it's public. Good start.

It's just most likely a javascript call of window.close, it's not that cool.

Nowadays instead of having the sub-systems you are referring to for storing data, many scaled databases use NoSQL and Redis for databasing and caching. The caching is probably the more scalable of the two because caching at any level has to do with usage and not all database data is used. Caching has allowed the most used data to be readily available. The limits of scalability may only require the system you described, but bigger and more complex systems like Twitter and Pinterest have been documented using database scaling via caching with things similar to Redis and Memcache. Keywords for finding more information are "cache/caching".

Problems with the sub-system of databasing are too many transactions (I/O) and the speed of getting the data and acting on it is very inefficient.

If you want to talk to me about it in more detail, message me on Twitter: @compooter or get my email at mayorpear.com

Immersion and starting from scratch on everything.

They do care about markup, but they care more about reaching the most audiences with the best experience. To do that they have to sacrifice valid W3C markup for markup that will display best in most browsers (and sometimes with browser-specific conditions). Another problem is the lack of markup dedicated to layout which sometimes breaks validity.

Google's own DuckDuckHack.

The web should be the first move because it is an easier pivot point for starting. With a website, you can give people a way to see your product and/or interact with it. It also centralizes your product under a findable URL. A website can also get many more users than one mobile platform can. Mobile discovery is lacking so as of now the web is the best way to start your project.