TimeScrub.js

TimeScrub.js is a NodeJS middleware application that allows simulations to record multiple steps along time and save those steps for later recalling.

To use, follow the following template.

var timescrub = require('timescrub');
var yourVariable = new timescrub.app();

//best fed JSON objects, but timescrub will try to work with anything, with varying degrees of success.
yourVariable.AddWatch(objectToWatch, "nameInStorage");

//In the gameloop.
yourVariable.Watch();

//And when you want to save.
yourVariable.Save("filename.json", function() { }); //Works via callback.

//And load...  Gives you a variable with the JSON in it.
yourVariable.Read("filename.json", function() { console.log(yourVariable.data); }); //Works via callback.

You can also install via npm!

Monogame Community Architecture Analysis

Monogame:

What we did:
My team and I researched Monogame primarily through its Github page, main website, and Google.  Before the project, I had crawled through the Monogame source and interacted with its developers on Github.  We attempted to augment our own research with "Git by a Bus", but coding limitations prevented us from running the sofware on a project of Monogame's size.

Some context and history: 
"From the website:  MonoGame is an Open Source implementation of the Microsoft XNA 4 Framework. Our goal is to allow XNA developers on Xbox 360, Windows & Windows Phone to port their games to the iOS, Android, Mac OS X, Linux and Windows 8 Metro.  PlayStation Mobile, Raspberry PI, and PlayStation 4 platforms are currently in progress.

In 2009 José Antonio Leal de Farias, an active member of the XNA community, started an open source project called XNA Touch with the goal of porting simple 2D XNA games to mobile devices.  He started from Bill Reiss’s SilverSprite and some bits of Mono.XNA and in December 2009 the first release which only supported iPhone was posted on Codeplex.
...
In March 2011 the project was renamed MonoGame and was moved to GitHub.  That same year support for Android, Mac, Linux, and OpenGL on Windows appeared.  Dominique Louis who joined the project in 2009 took over as the full time project lead."

What is the community?
Monogame has had 8 main developers over the course of its entire life.  Currently there are 4 : Steve Williams, Tom Spilman, Andrea Magnorksy, and Jacob Anderson, who also approve patches.  Over the course of the project there have been 138 contributors, and 6,089 commits.  Tom Spilman acts as the lead developer for the project, and is probably the best person to contact if you have additional questions.

Monogame has a large community of developers behind it, which has steadily been growing as more and more indie developers use it and give credence to the project's credibility and stability.

Would the project survive the raptor test or if 20% of contributers were killed?
My assumption is that because monogame is starting to get essential, and because the people using it are in a position to also write code for it, it would get picked up again.  While killing a large portion of the developers would be a huge detriment to the project, it would probably recover. One of monogame's strengths is that its userbase is often involved in development - this means that there are a lot of people with stake in the project, and an ability to code and improve upon it.

Monogame's Documentation/ Bug Reporting/ Quickstarts to contributing: 
Monogame has a large amount of documentation by pure virtue of being able to use most of the old XNA documentation.  It's very easy to start using.

The source code itself is also well documented; there's a good quickstart guide and the code is well-commented.  Outside of that though, you'll be somewhat on your own as to finding what bugs/features to work on.

Bugs/issues/milestones are managed through GitHub's issue tracker, which is managed by the lead developers.  This is also where most of the conversations take place - it's here you'll find talks about release schedules, future changes and merges, and so on.  Monogame has no mailing list and little activity on any IRC channel.

Is contributing to Monogame right for you?
It depends on what you want.  Monogame isn't terrifically helpful getting you set up or helping you through problems.  That may be something you like (independence, less scheduled accountability) or it may be a problem for you (less help when you run into problems, harder to talk about specific issues, harder to get people to work on things)

Any conclusions?

• There are a small number of people in charge, but those people are taking input from a large number of independent contrubuters, each with a fair amount of power over the direction.  Merging in large amounts of code requires communication and getting to know the community.
• There is a large sense of independence in the project.  The largest amounts of development are being done in forks by other people, and then after significant amounts of development (getting a game released, etc...) then merging it back in.  There are positives and negatives to this approach.
• The community doesn't do a great job holding your hand, but there's room to experiment. There's a strong DUI ethos, at least that we saw.

Callaway Coefficient of Fail : I was less than impressed with how this list is calculated.  It has less in common with a serious, accurate assessment of quality, and more in common with a series of half-joking attacks on the author's personal pet-peeves. That being said, it was a requirement.
-------------------------------------------
Size: + 0
Source control: + 0
Building from Source: + 50
Bundling: + 0
Libraries: + 20
System install: + 20
Code oddities : + 20
Communication : + 15
Releases : + 0
History : + 10
Licensing : + 10
------------------------------------------
145 - So much fail, your code should have its own reality TV show.

Our assessment: Monogame is here to stay.  The community is still growing and the project is still maturing, but nothing's going to get rid of it anytime soon.  It is, by all sane measures, a highly successful project.

Open source proposal: vAnalyze.js

vAnalyze.js: Daniel Shumway

Description : vAnalyze.js is a script that can be pasted into the Chrome Dev Console to infect any javascript functions being called on a webpage and allow the user to run real-time analytics and to inject code into those function calls.

Dependencies : None.  vAnalyze.js is a pure javascript library.  It is intended to be used with Google Chrome.

Upstream Repo : Github and Github Gist.  Because vAnalyze.js doesn't, and indeed, can't be installed on a computer, it doesn't make sense to bundle it as a library.  The most useful way to show people the code and make it available is to put into a single location that can be easily copied and pasted directly into a console.

Hardware Needed :  None (Will be running/demoing the code on a raspberry pi)

Upstream Mentors : Cody Van De Mark

License : MIT

Milestones : 

• Week 2: Setting up the functionality and planning out the architecture.
• Week 3: Finish code up, get individual components working together.
• Week 4: Testing code/documentation, adding additional tools for code analysis as time permits.
• Week 5: Packaging, more documentation

Javascript: Viral Functions and "Use Strict"

I've been making a lot more progress on viral functions over the course of the last couple of weeks.  The big breakthrough has been rewriting a method to get access to calling functions, and figuring out a feature of the Chrome Dev tools that allows easy access to those functions.


Functions in javascript are either passed by reference or value. I'm honestly still trying to figure that out, because I was almost sure this code wouldn't work until it did.

Regardless, this is a big deal.  I use arguments.callee.caller to get references to the functions that interact with my infected functions.  If it didn't work, I'd have no way to infect other functions that called mine.

The other big thing that I alluded to earlier was learning that "use strict" will only ever apply to the current script.  If this wasn't the case, I couldn't use arguments.callee.caller at all, because scripts that included "use script" would just throw errors as soon as I injected my code.  But.... that's not the case with Chrome, and it remains a viable tactic.

RIT Linux Users Group: Compiling the Linux Kernel

I recently joined the RIT Linux Users Group, for a couple of reasons.  Firstly, as part of my FOSS classes, I'm required to regularly attend tech meetups in Rochester, and the LUG was one of the few that I could actually get to.  Secondly, and obviously more importantly, I'm interested in getting more of a refresh on Linux.

When I got into college, the OS and I had a bit of a falling out, in that I stopped having the time and hardware to run it.  I want to be able to learn some of the more intermediate topics without forcing myself to exclusively use Linux or do a ton of experimentation on my own, and LUG is absolutely perfect for that.

Anyway, this week's presentation was on compiling the Linux Kernel!

I won't get too detailed about this, because I was still trying to wrap my head around the topic when our meeting ended.  That being said, the big takeways I had were:

• It's very valuable to do customization like this - contrary to what you might think, the Linux kernel can actually waste a lot of space and processor time in it's default state.  You're not just looking at trivial gains from an exercise like this.
• The big things you're looking to do is disable things that you don't need - like Mac OS drivers on your Lenovo laptop.
• You can do this graphically!  Which was a cool surprise, but it still doesn't necessarily make it easy.

Not having a Linux box I'm willing to test this on, I'm probably not going to go much farther down this particular rabbit hole, but I'm OK with that.  Like I stated above, I want to be able to tiptoe back into some of the more intermediate topics, and this was an awesome chance to do that - I'd have never researched any of this stuff if I wasn't at LUG.

Team Proposal: Monogame Community Evaluation.

Team Proposal


List your other team members below



Name
email
Daniel Shumway
shumway.danny@gmail.com
Liam Middlebrook 
ljm2906@rit.edu
Brian Escriche
bke2759@rit.edu




Which project did your team choose?

We'd like to examine the monogame community to examine their community's health and the long term feasibility of the project.


2-liner description of the project?

Monogame is an Open Source implementation of Microsoft's XNA API, started to revive the API after Microsoft abandoned it and to expand it to other platforms.

What will each team member's role be?

Team roles are still under discussion.



Daniel Shumway : Research, writing

Liam Middlebrook : Research, writing

Brian Escriche : Research writing


Source Code Repository URL?
https://github.com/mono/MonoGame


How will you communicate with them? (i.e. IRC Channel, Email Addresss, mail lists, issue trackers, etc...)
Monogame has an IRC channel, but Github will likely be the more active place.  In addition, we plan to try and talk with Ethan Lee, who's been behind a large number of the recent game ports.


What are the easy parts?

The monogame community is large, and it's a well established project.  It shouldn't be too terrible finding information for it.



What are the hard parts?

My experience thusfar has shown that the community doesn't communicate overly well on IRC.


How will you overcome both?
We'll communicate on Github and via personal messages to key parts in the community.

Getting started with contribution: Wikipedia, Github

What's all this?

I don't have a lot of experience working with other people on Open Source code, so within my FOSS classes, I wanted to try a couple of different methods of contributions just to get my feet write in a variety of ways.  These are both areas that I'd like to do more work in, so expect me to (assuming I have permission), do additional contributions for both of these projects.

Wikipedia :

• What I edited: Construct 2
• What I did: Added sources, reorganized article, proposed further changes to the community that will be implemented soon.
• How I approached: I spent some time learning the editor with small changes (adding sources), before I thought about larger formatting changes.  Once I felt comfortable with the interface, I switched the formatting around an extremely small amount and waited to see if anyone would yell at me.  I then attempted to write out my proposed changes in the community talk page to give people yet more time to tell me if I was about to kill someone's baby.  I'm now ready to implement the changes.
• Links to the logs: https://en.wikipedia.org/w/index.php?title=Construct_%28game_engine%29&diff=597145775&oldid=596445136, https://en.wikipedia.org/w/index.php?title=Talk%3AConstruct_%28game_engine%29&diff=597369714&oldid=596070839
• The moral: I've kidnapped the Construct 2 page, and if my demands aren't met I will kill one hostage every hour.

Github:

• What I patched: Monogame
• What I did: Fixed a bug that caused deactivation and activation events to be fired off multiple times during Monogame initialization.
• How I approached: I downloaded and got familiar with the source code before even looking for bugs to fix.  Monogame makes compilation interesting; you need to set up a test project on your own in order to test anything.  When I found bugs, I tried to avoid stepping on people's toes as much as possible, so I tried not to attack bugs that would require me to refactor lots of code.  I went with the assumption that because this was a large project and I wasn't familiar with it, the more code I touched the worse.  Before I did a commit I tried to talk about the changes with the community and get feedback on it.  The monogame community isn't overwhelmingly active, so this was sometimes more of a challenge than I expected it to be.
• Link to the log: https://github.com/mono/MonoGame/pull/2255
• The moral: When I put this on my resume, I'm not going to mention that the end result was just moving around two lines of code and re-commenting stuff.