torsdag 9 april 2020

Big Suzy Cube News: Gear And Google Play Pass!

#SuzyCube #gamedev #indiedev #madewithunity @NoodlecakeGames

It's been a while but I've got some big news for fans of Suzy Cube and stuff! Oh! And a whole new way to enjoy Suzy Cube on Android! Hit the link for the detail!
Read more »

söndag 29 mars 2020

Tech Book Face Off: The New Turing Omnibus Vs. Patterns Of Software

I'm churning through tech books now, finishing off a bunch that I had started a while back, but couldn't find the time to finish until now. The pair that I'll look at here are a couple of older books that I picked up through recommendations on blog posts. The first one, The New Turing Omnibus: 66 Excursions in Computer Science by A.K. Dewdney, is a survey of 66 topics in a wide range of areas of Computer Science. The second book, Patterns of Software by Richard P. Gabriel, is about advice and experiences on a variety of topics in software development. Whereas NTO is of a strictly technical nature, Patterns of Software has much more of the human aspect of working with computers and software. Let's see how these older books hold up today.

The New Turing Omnibus front coverVS.Patterns of Software front cover

The New Turing Omnibus


With the new edition published in 1993, this is definitely an older computer science book. That can be okay, if the author sticks to the more timeless aspects of computer and software design. For the most part, this is the case in NTO, but a few of the chapters—especially the ones on VLSI computers and disk operating systems—are definitely dated and nearly beyond usefulness. The topics vary far and wide, though, and are generally grouped into eleven subject areas with the following breakdown:
  • Analysis of Algorithms (8)
  • Applications (7)
  • Artificial Intelligence (5)
  • Coding and Cryptology (3)
  • Complexity Theory (6)
  • Computer Graphics (3)
  • Data Structures (6)
  • Automata and Languages (5)
  • Logic and Systems Design (9)
  • Theory of Computation (9)
  • Miscellany (5)
The miscellany chapters could honestly been grouped into the other categories, and the three computer graphics chapters were just as much algorithms or data structures as anything, so nine categories would have been sufficient. That's fairly inconsequential, though, because the topics were presented completely haphazardly anyway. The chapters would go from Karnaugh Maps to the Newton-Raphson Method of finding roots to minimum spanning trees without any ceremony whatsoever, leaving the reader grappling for a solid structure to hold on to.

Each chapter is a brief 5-7 page discussion on the given topic followed by two or three problems related to the topic as practice for the reader. These problems commonly explored points glossed over in the text. The topic discussions read like blog posts and don't give more than a cursory introduction to the sometimes deep and complex subjects they are covering.

I had high hopes for this book, considering the glowing recommendation that Jeff Atwood gave it back in 2007 on Coding Horror, but I just couldn't get into it the way he did. I found the treatment of the topics that I had already learned in much more depth, mostly from studying in college, to be tedious and unremarkable. The remaining 25% of the topics, mostly on the theory of computation and automata, was quite difficult to understand from the short expositions given, and I would have to do more extended studying with a book like the Introduction to the Theory of Computation to get enough of a handle on the subject to answer the more difficult end-of-chapter problems.

I may not have been the right audience for this book, but I had a lot of trouble figuring out who the right audience would be. The material was so superficial that I didn't find any additional insights or valuable practice from any topics I already knew about, and those topics that I had little exposure until now were nearly completely opaque from the text. It was weird. The book didn't seem to fit for either a novice or a (moderate) expert on any of the topics, and the fact that related topics were strewn throughout the book, separated by completely unrelated topics, made it even more frustrating and less helpful. Maybe if you were using it as a supplement while studying some of the broader subjects for extra practice, it would prove to be of some use, but I'm not even convinced of that. I have to give this book a solid "no" at this point. There are much better books out there on the subject areas covered here.

Patterns of Software


This was an odd book, and not at all what I expected. I had expected a book relating advice to the reader on how to design and develop software. What it is instead is an extended comparison of Christopher Alexander's work on patterns in architecture to patterns in programming followed by speculations on programming languages, advice on learning to become a good writer, and a significant part of Richard P. Gabriel's life story. It was a strange mishmash of things that didn't quite hold together as a cohesive book.

Throughout the first part on how Alexander's books—the most well-known being A Pattern Language—relate to programming, Gabriel quotes Alexander extensively, to the point where I almost felt like I was reading Alexander more than Gabriel. He also did not spend enough time tying all of these quotes into programming and software, so much of the time I was left wondering if the book was just a review of Alexander's works.

Gabriel did have some insights into programming that resonated well, such as
Maintaining compressed code requires understanding its context, which can be difficult. The primary feature for easy maintenance is locality: Locality is that characteristic of source code that enables a programmer to understand that source by looking at only a small portion of it. Compressed code doesn't have this property, unless you are using a very fancy programming environment.
We must be careful to strike the right balance when coding so that we don't unnecessarily obscure things that should be simple and easy to understand just for the sake of abstraction. Sometimes it's better to lay out a process linearly so that it can all fit on the screen at the same time instead of slicing and dicing to the point where the poor sap who has to debug the code needs to chase the flow of execution through dozens of functions and variables across tens of files. This insight gets at one of the themes of the book on making code habitable:
Habitability is the characteristic of source code that enables programmers, coders, bug-fixers, and people coming to the code later in its life to understand its construction and intentions and to change it comfortably and confidently.
This idea of habitability is a worthy goal, and Gabriel returns to it often in the context of Alexander's architecture patterns:
What Alexander seems to be saying is that if we try to use modular parts (solid building blocks not easily molded to the current circumstances), then the overall structure of the thing built with them may become overly constrained by their shape. In programming, if a set of large abstractions does nearly the right thing, it is tempting is [sic] to use them and to bend the structure of the surrounding program to fit them. This can lead to uninhabitable programs.
It seems like much of modern software development has become exactly this, where we as programmers have been reduced to searching for and slapping together all of the packages we need to meet the given software requirements. In this process of moving towards extreme reuse, something has been lost in software development, and this is speaking from a perspective more than twenty years after this book was written, with reuse being much more common and extensive than it was then. This thing that has been lost is Alexander's "quality without a name."

Both Alexander and Gabriel spent a lot of time trying to define this quality without a name, but neither succeeded very well. Gabriel critiqued Alexander's choices in descriptive words, like "simple" and "cohesive," but while he was right that the word choices did not do the concept justice, he did not do much better in clarifying what the quality was. Even more troublesome than defining it, Alexander found that he couldn't replicate this nameless quality by enumerating the patterns of architecture. It's not something that you can create simply by combining known good patterns in a building.

This difficulty of codifying quality is true for almost anything we do. It's as true for architecture as it is for programming as it is for every form of craftsmanship, and it seems obvious that this would be so. We can't package up and mass produce quality that simultaneously exhibits beauty, elegance, efficiency, and function. Reaching the point where you can produce things of such a high level of quality takes decades of experience, creativity and experimentation. Most people will never reach the level of craftsmanship where their work is elevated to an art form.

It was frustrating that Gabriel danced around that conclusion for most of the book, but never really committed to it. He did spend a fair amount of time on silly tangents, like the chapter where he claimed that the development of programming languages was at an end, and C was the ultimate answer. That prediction looks mighty short-sighted today.

The rest of the book, detailing Gabriel's struggles through college and running a software business, was sometimes interesting and sometimes not, but it didn't have much to do with the first half of the book on patterns and code habitability. In general, his writing was quite repetitive and disorganized. He would introduce a new topic or part of a story by giving away the conclusion as if it was a stand-alone statement, and then proceed into an extended discussion on it. A few pages later I would realize he was talking about the details of a story that I had thought was just an isolated observation and we had moved on. This writing style was quite disorienting, and the constant repetition of certain observations or narratives, each time stated as if it was the first, became fairly annoying.

Between the sparse real insights and disjointed structure of the book, I can't recommend Patterns of Software at all. The software development advice can easily be had in much better books without the extended and largely irrelevant fluff. It's unfortunate. I feel like I really struck out with this book and The New Turing Omnibus, but sometimes that happens. Maybe the next couple books I read will be much better.

lördag 28 mars 2020

Cross-compiling Rust To Linux On Mac

In my last blog post I said I wanted to spend some time learning new things. The first of those is Rust. I had previously tried learning it, but got distracted before I got very far.

Since one of the things I'd use Rust for is web pages, I decided to learn how to compile to WebAssembly, how to interface with Javascript, and how to use WebSockets. At home, I use a Mac to work on my web projects, so for Rust I am compiling a native server and a wasm client. But I also wanted to try running this on redblobgames.com, which is a Linux server. How should I compile to Linux? My first thought was to use my Linux machine at home. I can install the Rust compiler there and compile the server on that machine. Alternatively, I could use a virtual machine running Linux. Both of these options seemed slightly annoying.

I've been curious how much work it would take to cross-compile, and I found this great post from Tim Ryan. My setup is simpler than his, so I didn't need everything he did. I started with these commands from his blog post:

rustup target add x86_64-unknown-linux-musl brew install FiloSottile/musl-cross/musl-cross mkdir -p .cargo cat >>.cargo/config <<EOF [target.x86_64-unknown-linux-musl] linker = "x86_64-linux-musl-gcc" EOF 

I then compiled for Linux:

TARGET_CC=x86_64-linux-musl-gcc cargo build --release --target=x86_64-unknown-linux-musl 

Unfortunately this failed with an error about OpenSSL. Tim's post has a solution to this. Before implementing that complicated solution I realized that I should't need SSL/TLS anyway. My server talks regular websockets, not secure websockets, and then I use nginx to proxy them into secure websockets. So I disabled the secure websockets with this in Cargo.toml, the file that has the Rust project configuration:

[target.'cfg(target_arch = "x86_64")'.dependencies] tungstenite = { version = "0.9", default-features = false, features = [] } 

At first I tried features = [] but that wasn't good enough. I needed to also use default-features = false to disable the TLS. With this, the binary built, and I was able to run it on Linux!

So now I have a Makefile that builds the wasm client, the Mac server for local testing, and the Linux server for production. Fun!

BUILD = build  RS_SRC = $(shell find src -type f -name '*.rs') Cargo.toml WASM = target/wasm32-unknown-unknown/debug/rust_chat_server.wasm  run-server: target/debug/chat_server  # local testing server  RUST_BACKTRACE=1 cargo run --bin chat_server  target/debug/chat_server: $(RS_SRC)  # production server  cargo build --bin chat_server  target/x86_64-unknown-linux-musl/release/chat_server: $(RS_SRC)  TARGET_CC=x86_64-linux-musl-gcc cargo build \      --release --target=x86_64-unknown-linux-musl  $(WASM): $(RS_SRC)  cargo build --lib --target wasm32-unknown-unknown  $(BUILD)/rust_chat_server_bg.wasm: $(WASM) index.html  wasm-bindgen --target no-modules $< --out-dir $(BUILD)  mkdir -p $(BUILD)  cp index.html $(BUILD)/ 

My Cargo.toml file is kind of terrible but it works so far for building the three outputs:

[package] name = "rust_chat_server" version = "0.1.0" authors = ["Amit Patel <redblobgames@gmail.com>"] edition = "2018"  [lib.'cfg(target_arch = "wasm32")'] crate-type = ["cdylib"]  [[bin]] name = "chat_server" path = "src/chat_server.rs"  [dependencies] wasm-bindgen = "0.2" serde = { version = "1.0", features = ["derive"] } bincode = "1.2"  [target.'cfg(target_arch = "x86_64")'.dependencies] tungstenite = { version = "0.9", default-features = false, features = [] } 

That's it for now. I'm not a big fan of writing client-server code in large part because I want my pages to still work in thirty years, and that's best if there's no server component. But I want to spend time this year learning things for myself rather than trying to produce useful tutorials, so I'm going to explore this.

Tim's blog post was a huge help. Without it, I would've compiled the server on Linux. Thanks Tim!

I've placed it on github.

I Am Alive Download For Free

I Am Alive Download For Free


SCREENSHOT





System Requirements Of I Am Alive Download Free

  • Operating System: Window XP/ Vista/ Window 7/ Window 8
  • CPU: Intel Pentium 4 or later
  • RAM: 1 GB
  • Setup size: 1.8GB
  • Hard Disk Space: 2 GB













tisdag 24 mars 2020

8-Bit Lent


We should all have a good strategy prepared for the spiritual battle of Lent- things we are going to deny ourselves from eating, extra prayers we are going to say each day, sacrifices in terms of comfort and sacrifices in terms of media.

Lent is serious, it is the badge of being a true Catholic.

Maybe one sacrifice you might make in terms of video games is to give them up completely and to give up all reading up about them. That would be a great offering to the Lord.

Another idea, and something I am going to take up is to reduce myself to only playing 8-Bit games, (and, of course, to abstain from gaming media on YouTube).

8-Bit games certainly can be a bit of a penance, they can train us in patience, in denying immediate excitement and pleasure, and they are very very basic. They are like a bread and water fast in terms of gaming.

Give it a try. 40 days, only 8-Bit, and of course, only games you can play legally,

fredag 20 mars 2020

Christmas 2019!

Happy Holidays to you all, thank you once again for your patience and for listening.

Music from https://filmmusic.io
"We Wish you a Merry Christmas" by Kevin MacLeod (https://incompetech.com)
License: CC BY (http://creativecommons.org/licenses/by/4.0/)

"Jingle Bells" by Kevin MacLeod (https://incompetech.com)

License: CC BY (http://creativecommons.org/licenses/by/4.0/)

"Wish Background" by Kevin MacLeod (https://incompetech.com)

License: CC BY (http://creativecommons.org/licenses/by/4.0/)

"Deck the Halls B" by Kevin MacLeod (https://incompetech.com)

License: CC BY (http://creativecommons.org/licenses/by/4.0/)

"Oh Holy Night" by Kevin MacLeod (https://incompetech.com)

License: CC BY (http://creativecommons.org/licenses/by/4.0/)

"Angels We Have Heard on High" by Kevin MacLeod (https://incompetech.com)

License: CC BY (http://creativecommons.org/licenses/by/4.0/)

"The Terminal " by Luca Fraula (http://www.lucafraula.it/)

License: CC BY (http://creativecommons.org/licenses/by/4.0/)

Other music from the Free Music Archive by

Borrtex
Dee Yan-Key
Kai Engel
Podington Bear
Squire Tuck
TRG Banks


Ornament photo from Dreamstime