React Tetris(github.com) |
React Tetris(github.com) |
Edit: Just as importantly, at least on a touchscreen, the arrows are on the right and drop is on the left, which is opposite of Gameboy but the same as a computer or TI calculator ;-)
That being said, I took a look at the code and the way Redux is being used feels kind of weird to me - pretty much a separate reducer for every kind of action.
Example: https://github.com/chvin/react-tetris/blob/master/src/reduce...
I haven't been able to find a free source for the actual ruling, but apparently a district court ruled in 2012 that the particular playfield dimensions, set of tetromino shapes, set of movement actions, and scoring rules are copyright-protected expressions of more general/abstract rules, and only the latter are ineligible for copyright [1]. To my untrained eye, this seems to parallel Oracle's "structure, sequence, and organization" argument for API copyright.
The case is Tetris Holding v. Xio Interactive, 863 F.Supp.2d 394 (D.N.J. 2012).
The text of the ruling is available a few places, for example on Google Scholar:
https://scholar.google.com/scholar_case?case=180648822600252...
Keep in mind though that it's a district court ruling and has pretty limited value in predicting other outcomes.
That sad, this is just fantastic, thanks a lot for posting!
I've recently discovered https://book.mixu.net/css/ and want to test if it actually makes it easier to think about css layout in the context of an app. Maybe I'll find the time to work through this and do a writeup.
Providing a blog post is completely different, as this is a narrative composed after the fact, not a historical record of lessons. Here, the author is explicitly choosing to reveal specific lessons learned, but has the dignity of concealing the learning mistakes by which they're particularly embarrassed. They can humblebrag about the hardships of writing something cool, like a JSON deserializer - nobody need know their embarrassing hardships, such as the 3 days they spent debugging, only to find they had a hardcode hiding in the variable init section.
Side note: that dinosaur looks a lot like the one in Chrome. Coincidence?
Does no one care what is the result as long as the developer put the "right" abstractions in making it?
Plenty of take aways from this Show HN for me. I can look at the code and understand how React was used to achieve this. Sure, this could be done with 100s of other frameworks or even plain C++ but thats not the point. But again, you missed the point.
I think it's a very cool project.
By the way, it's pretty dumb and shortsighted to depict flash as a neanderthal, because both its capabilities and its ease of use are (were) way beyond what current JS frameworks offer today (and in the upcoming years, at least).
Tip: Fork the repository and use that as your official side project when you look for a job.
I'm saying fork to put all of that under a github.com/yourname account with all contributions edited to be from yourname@gmail.com
Thanks for the life hacks.
We've seemed to replace the merits of direct functional efficiency with a novelty of complexity.
This is how people and communities learn. They do small projects to see what is achievable. There is nothing shameful about it.
About the parent poster: he is just an adult equivalent of a kid that came into the room, scrapped other kids drawings and told them they are all suckers. Otherwise said, just someone having emotional meltdown and taking it on the random people around. No reason to take him seriously.
However it is undeniable that there are overkill levels of abstractions in play here, for the purpose of using what is currently the most commercially viable web framework. This is like taking FizzBuzz Enterprise Edition seriously for being written in Java.
>just someone having emotional meltdown and taking it on the random people around
I won't stoop down to your level of using personal attacks. You don't know me.
You're taking his depiction of Flash out of context.
https://github.com/chvin/react-tetris/blob/master/README-EN....
He was clearly only comparing the different solutions in terms of audio capabilities.
I can appreciate how much of a gigantic leap in capabilities Web Audio API offers compared to HTML5 audio alone, so I can vouch for that part of his depiction.
I haven't ever worked with Flash audio, nor Flash itself in general though, so you may still be right about him being unfair and shortsighted in making that comparison in the context of audio capabilities, but I think it's still an important distinction to make if that was in fact your critique.
ELEVEN YEARS ago Flash was already capable of both playing and recording audio from multiple sources, using several different codecs and offering the usual bells and whistles you're expected to find in any multimedia framework (vis.eq., channels, etc). And everything working exactly the same way in every browser equipped with a flash player.
And I'm taking eleven years ago because that's when AS3 was released. Flash had considerable audio support before that anyway.