It's not exactly a traditional role-playing game, but I've been very taken by Microscope. You can play it with a trello board it's pretty simple. It's more like world-building story-telling I guess.
I haven't really worked with any client-side languages before, so I picked up Elm because it was similar to other languages I'd used in the past. It's got a unique approach to things and an incredibly active community. It's adoption is not as widespread though. Most of my coworkers swear by React and Vue.
I was familiar with Haskell but I wouldn't consider myself a functional programmer, most of my career has been on the Object Oriented side of things. I actually found it to be quite approachable. It's charm has stayed so far as I've found it offers a lot of advantages in terms of code re-use. The elm-lang.org resources, hosted Core lib documentation were most of what I've used. They have live examples in a web repl that is helpful. I would recommend checking with their git though as the pace of the languages development can go through spurts.
I've found that not just with open-source but even in the private sector (engineers at big companies can also be extremely prideful and opinionated) I need to essentially treat them with kid gloves, even if they're a 50 year old bearded man.
I acknowledge the merits of their work in the body of my comments, and I posit that I'm merely trying to further refine their already good ideas. Did I mention how good their ideas are? What great ideas that I'd love to contribute to. Each time I get push back I acknowledge the points addressed, and I carefully guide them to realizing that my pull request is in fact their idea, and it's a great idea because all their ideas are great.
for adressing PR comments I usually try to classify them first upon whether or not their filler (meaningless), require addressing (valid questions) or require action (code change). Sometimes issue tags and stuff can also be helpful. I'll typically go back through the comments after fixing stuff, and like a :thumbs-up: to say i read it, and i'll @ them link to the change if it's action required.
It's really tricky man. Even though we all call ourselves engineers--we're all still just humans. Just remember you're dealing with humans and if it comes down to you've got your own fork you maintain--well make it better and then people will use your fork :D
I want something like a Herman Miller Embody or Aeron but with a working toilet built into the base of the seat that maybe runs to a septic tank on the back rest or something. I waste a lot of time getting up to use the restroom.
Now that I think of it, I'd like something like this too. Would pay $100 more for this type of seat. OP, you asked for an idea, now you got it. Go build it... wait, you were waiting for someone to say a To-Do list for cats?
hahaha, This one was really helpful and something probably I would have never thought of, but now that I think about it, I would also like to use something like this. Even I spend a lot of my time going to toilet again and again.
taskwarrior. command line todo list, has a sync server for sharing tasks across devices. I like it because i can just type `task` in the shell and see what i need and keep working, then if i finish something it's `task x done` it does burndown charts and stuff too, all from the shell. nice api for plugging into and of course because it's in the shell it's already very extensible.
This is lots of companies I've worked at. Producing vaporware solutions for problems that may or may not be defined via user requirements (if defined at all). I'll just tell you about the worst one I worked at:
Under the hood, the company was down to 4 engineers (we sold the company as a team of 30 engineers). We were basically doing Ponzi-style SOWs promising time to clients over time another had paid for, etc. Lots of our 'solutions' were just white-labeled third-party software bundled up into a shitheap. We didn't have any actual IP because all of the stuff we made was licensed by the hosted providers we used. We actually stopped really acquiring any new tech or updating or methodology maybe a year into me working there. My boss shifted focus onto social media (blog posts about cloud shit, tweeting about cloud shit, facebook about you guessed it--cloud shit.) He even went as far as to spend ~20,000 on high end production and recording/streaming equipement and software to start doing live webinars about more, yes, cloud shit. The content of the webinars was whatever the engineers could manage to scrape together at 2am after finding some time in their massive stack of actual work to do. Our boss never learned how to set up the shit, the webinars barely ever streamed successfully, and the social media best I know never made a mark.
I've been gone a while but last I heard the CEO is still hellbent on being the most widely visible adopter of the cloud in the world.
I'm not familiar with your setup, so I'm not sure how much of this is applicable, but I've seen a few different approaches, the all more or less go like this:
* choose a configuration state manager like Salt, Ansible, Chef, Puppet, etc. Of all these I'd probably say Salt is the simplest for somebody approaching this methodology.
* choose a source control management system -- I'd just go with git, and host something on github or gitlab or bitbucket or whatever.
* choose a secure storage medium for the variables that are going to be loaded into your configuration state manager.
* choose some form of automation management tool, Jenkins, Thoughtworks Go, TravisCI, CircleCI, w/e.
You're going to use these in conjunction to gain the following: when a developer pushes code to a specific branch, this push triggers a build on the automation server, which is able to package the code, and distribute it to the nodes managed by your configuration state manager. Aka, a push to your repo makes it all happen (with testing, etc as gatekeepers to deployment of course.)
I'll describe a basic setup I've encountered in the wild using Salt in a master-agent setup (since it's the most basic imo, aside from headless):
-> developer writes some code
-> developer pushes that code to github
-> a POST webhook containing branch info is sent to my Jenkins box
-> Jenkins initiates a build job that pulls down that branch of code
-> Jenkins uses make (we use make) to build the code branch.
-> Jenkins deposits the built code artifacts on a fileshare somewhere.
-> Jenkins calls to the salt-master to update all nodes.
-> the salt master (which could just be hosted on the Jenkins i guess) tells all minions to update
-> all minions pull the new code and HUP themselves.
Salt uses yaml files to define the desired state you want, this includes installing deps, installing config files, loading files, blah blah.
I use Jenkins Groovy pipelines (which I'm not that crazy about) to ensure that the Jenkins jobs themselves are captured as code and are repeated the same way each time across my make build steps. I work in AWS, so the machines I use, the bootstraps they boot with, the desired state config files, and everything are defined as code in some regard.
You should attempt to push for 'desired state' and move towards 'immutable state'.
I would also strongly consider looking at the other options aside from salt, it's only so-so.
- sent from my iPhone