Of course I did. How could I avoid it. I tried for so long, saying “Oh that is too expensive” or “You don’t know the first thing about 3d design” or any number of things. Until the only one that was true (don’t lie) vanished. Suddenly, Seymour! Under 200 bones and I could be printing!
So I ordered an Anet A8 (of course you did john, of course you did) and started reading, watching and taking notes. I made spreadsheets (so predictable). I joined several youtube channels. (Jennifer A. Lewis, Toms3D, 3DMakerNoob, Maker’s Muse, and CNC Kitchen)
Some really cool stuff. Mostly what I saw were folks thinking and having fun.
So it arrived, I built it and clicked a few things for a while, inserted some stuff and picked the most complicated model that it came with…
It did not end well…
I have always preferred to work on the back end. It seems more peaceful there. The front end is all colors, moving stuff, and clicks!! Why should I care about clicks… I respond to requests no clickity click click demands! I am fine seeing JSON shoved on the screen, I will parse it visually, personally. I don’t need fancy filters, sorters and interfaces for data.
This opinion puts me most certainly in the minority, so as every good developer does, I forced myself to do something that made me uncomfortable, make a front end. A little background, the project is a way for me to organize my interviews. I needed a place to hold the questions, let me run through them, add notes, and rate the candidate etc.
The api was written with hapijs, my new personal favorite node framework. I was waffling about what to choose for the client side of things. I have already built a few things with Angular 1.5 so I was contemplating Angular 2, but that would go against the reason I am doing this in the first place. I mean if I am going to go out of my comfort zone, it might as well be way out. I could do it in pure vanilla js, but again I am quite familiar with that.. Come on John! Think… think… A-ha! React. I hear about it constantly. It seems to solve some issues with rendering speeds. It has cool terms like ShadowDOM and JSX that remind me of hackers and superbikes in a cyberpunk movie.
“ShadowDOM leapt, turning mid-air. Using a neural link to control JSX superbike, it started just before her ass slammed into the seat and exploded violently forward…”
I am a few days in now. I have the basic CRUD working, and you know what? I don’t hate it! I like the way react apps come together. Nice and modular, with plenty of opportunity to build reusable components, really fun stuff. So I guess the lesson learned is to keep yourself confused and uncomfortable. Sounds like fun!
I have been working on my next tutorial. It will be a hapi.js api (maybe even with a React/Redux client) as close to production quality as I can get without a different (aka better) hardware infrastructure. Quality error messages, logging, input validation, fully documented, authentication with scopes and most importantly testing with 100% code coverage.
This is what I am currently working on and it’s been interesting learning how Hapi.js gets tested and what differences configuration over coding makes in my approach. So far I like it even though I am struggling with some specific routes. It is always fun to learn something new and feel that struggle again. I certainly prefer to have to work at something for a bit over working on the same thing over and over again.
I should have something ready in the next few days, maybe a week! I swear I just love coding so much!
It is just Numbers and Dots, right?
I just released a new version of software. I called it 1.0.0. Why did I do that? Really it was because that is just what I do. When I make a very tiny change I adjust the last number up. When I have enough tiny changes that I can bundle them up I adjust the middle number and when I have a significant number of those changes I adjust the first number.
Is this right? No, no it is not. So it’s time to figure this out. Let me go to the source:
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards-compatible manner, and
- PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
This makes way more sense. When you make incompatible API changes the major version must change, otherwise it is just extending the current versions functionality (still backwards-compatible) and finally if you are making changes, that don’t add functionality but fix originally intended functionality while maintaining the same backwards-compatibility it is a patch.
Why should I care? Do you want to live in dependency hell? I thought not. The more complicated software gets, the more likely conflicts occur among dependencies and interdependencies. How do we avoid this? By making sure that when we write a library with a public API we show how it’s used and how it will not be used. Once these restrictions change we know we have to think about bumping up the major version. Those who want to keep their code working can stick with the working major version until they have reviewed potential impact and decide to upgrade or not.
It is not overly complicated, but I highly suggest reading the full spec to become fully enlightened.
Just in case you pushed up a change with something that should remain hidden! Not that any of us have ever done this, but we all know someone who has. A nice simple way to purge that data. Go here!
Dreams are great. Dream big, that’s what they always say. As a programmer you must retune this concept to dream within a reasonable scope. In this post I will go over my original concept for my second solo week project and then what actually ended up getting created.
- Authenticate a User
- redirect based on user type
- if player show player dashboard
- if storyteller show storyteller dashboard
- allow many authentication methods
- Create a Game Container
- Game state aware dashboards
- if game activated show game active dashboard
- if game is not activated show lobby style dashboard
- Integrated Chat
- allow for slash commands
- /init rolls initiative (based on character sheet)
- Show users profile picture in order on the side of the chatroom
- /roll <NUM> rolls the <NUM> of six sided dice
- Character Management
- Rules based character creation
- Import of xml files with weapon info
- Chat aware leveling system
- Save a history so you can ‘replay’ at times in the past
- Game Management
- Create a game
- Manage individual game sessions
- Scheduling and invites
- Calendar for in world and real world
- Asset Management
- Sound board
- Fog of War
- Maps with player/npc tokens
- NPC Management
- Scale to player level
- Combat Helper
- Name Generator
- NPC Generator by type
- Much Much More!
What did I end up with? A combat assistant. I use it, it works but oh man is it not what I had in my original vision.
So what did I learn? Iterative thinking should be core to project conceptualization. If I had only thought of my program as a combat assistant I would have been very happy with my results. However because I had such grandiose visions of the first iteration I felt I let myself down.
It’s all about the MVP baby! Change that mindset. It’s awesome I had so many ideas, but if only I thought about them as user stories in the backlog and the MVP as my main goal my personal satisfaction would have been much higher in the end.
The notes get less and less as we are in sprints longer and longer. I will try to figure out a way to transfer the notes/diagrams without scanning etc. For now:
More Data Structures
Linked list – has a head and tail, with pointers from one list member to the next list member.
Graph – is a network of an arbitrary number of connections.
Binary Tree – node with at most two children and one adult. The left value is less than the parent is less than the right child.