Wednesday, May 14, 2014

Final Post - Thoughts

So, class is over and I've got a few thoughts to give on the class as a whole. I feel like I learned a lot about the software engineering process. The class was tough, but fair. Other than the hiccups with mid-semester evaluations, everything seemed to be designed to help us get a finished product out the door.

I'm really impressed with how much work my teammates did, I feel like I under performed, but it was difficult to find anything that needed to be done that wasn't already being worked on. Great work ethic from everyone, and great quality of work.

The other projects were all amazing. I continue to be amazed at how fun Automaton looks, and I think with a decent soundtrack it would do well on the App Store and Google Play. I found myself checking back on it once it went online and playing a few levels. UNM Visual scheduler was, of course, incredible, and absolutely deserving of first place. It's a headache reducer when signing up for classes, and I would not be surprised if it got bought out by the university and wound up being the new system in a year or two. The other three unfortunately don't really appeal to me much, as I am neither a skier or own a vehicle, but they are solid, marketable products.

Demigod, I feel like we could have done more with it, but we were especially careful to stay on spec and not let feature creep ruin us in the end. Matt Smith's leadership and experience in development were a great help at this, making sure we didn't go overboard and got everything done on time.

All in all, this was a great experience. I learned a lot about group dynamics and actually saw a project through to completion. Even as far back as writing our proposals gave me the tools I needed to make my own projects a reality.

Thanks to everyone in this class, and a big thanks to my teammates and professor Ackley.

Monday, May 5, 2014

If it codes like a duck and compiles like a duck, it's probably a duck.

Something I've always known Ruby could do, but never knew there was a word for: duck-typing. In short, duck-typing is object-oriented hierarchy without explicitly defining two things as being of the same family. Basically, where Java would throw a compile error if you were to use a "Person" class when you asked for a "Duck" class, Ruby would compile just fine, and even run it if the "Person" class has a "Quack" method that you call.

I didn't really use it too much in the assignment, but I do like the naming for it. It's very evocative of it's function and a decent little joke. Programmers tend to have a strange sense of humor.

Saturday, May 3, 2014

Redmine

So, my rails experience in this class is actually getting me more work at my job due to how awesome rails is. I've been tasked with re-doing our ticketing and point of sale system in Ruby on Rails over the summer. I've spent some time actually researching gems and services, and come across a program called Redmine.

Redmine is a issue and project tracking system, similar to the tracker on Bitbucket that we're using for Demigod. It's built in Ruby on Rails and is open-source, so I'm planning on integrating it into my project at work in the coming weeks. We already use a similar system in OpenERP to keep track of repair orders, so using Redmine in a much more customizable format would be a great help to our organization.

Thursday, May 1, 2014

Some linux-ey goodness

So, I know it's not particularly related to the class, but lately I've been working on setting up a Network Boot. The idea is, customers at the shop can bring in a computer, connect it to the network, and boot up the proper OS.

This was easier than I was expecting. My boss did most of the heavy lifting, setting up the DHCP and TFTPBoot, but I managed to get my first experience with Linux menuconfig. It's a very simple scripting language, really, and it's actually fairly similar to rails, or at least the way it handles partials and html. Menuconfig files reference each other with one line, effectively putting the entire contents of one file in its place. Menuconfig even writes a bit like HTML, with just about everything wrapped in begin and end tags, and nests to create a form. What's surprising is how much customization you can do in it. You can effectively lay out the text anywhere, you can insert images, and capture all sorts of inputs. That got me thinking, is menuconfig turing complete? It would be pretty interesting using menuconfig like a programming language. You could make simple programs that boot and run without even loading an OS. With the network boot thing, it might be possible to do a menuconfig on PXElinux that will, for example, image the drive over the network before selecting the reinstall option to automatically back up the data before going through with the reinstall.

It won't be done any time during this semester, but it'll be fun to work on over the summer.

Tuesday, April 22, 2014

Under the hood is nice... until the hood breaks.

So, rails. It's good. Really good. I've sung its praises before, but I do still find myself having troubles on occasion. Usually, when you have a problem with your code, it's easy enough to step through it and mentally envision the state of the code, effectively becoming a human compiler. In rails, though, that's just about impossible. I've always said my biggest gripe with Rails is it's abstraction. Basically, each object can have dozens of files in the file system determining it's code. Knowing what has scope where, which function call you're using, where the offending function is even defined is all difficult. I suppose using an IDE like Aptana would make things a bit easier, but it's still a bit difficult to get a cognitive map of the file system. Right now, I'm having trouble with some database entries, and I have no idea where. I can't seed the database, the seeds file is running completely fine (debug statement ahoy!) and the database is up and running, but one specific type of model is just not loading.

I'll probably ruminate on this for about an hour or so and realize a typo or something, but until then, I'm just left here cursing the abstraction layer for not giving me more information.

Monday, April 21, 2014

Presentational Responses

So, it's our second presentation today. And again, we're feeling the sting of no prep time. Last week, we were told we were presenting again, but not informed the week before. Our group has trouble meeting during the week due to work schedules, and this Sunday was Easter, so a group meeting was out. We did all we could during the week, and I feel like we definitely made improvements, but a bit more heads up would have been appreciated.

That being said, we are certainly better off than we were last week. A few improvements that were suggested were reducing the statistical overload, fixing the Facebook trouble (my bad), and a few other minor technical problems that will definitely be ironed out by the next presentation. I'm hoping there aren't any more before the final, though...

Saturday, April 19, 2014

Easily doing things the hard way, or hardly doing things the easy way

A situation came up during a group coding meeting that brought up a design principle that I feel most of us are fairly conflicted on. When attempting to solve a problem, at what point have you spent more time trying to find an easier way to do something than you would have spent doing it the hard way?

The situation was simple, we needed to do a validates_presence_of field for one specific method, not the whole object. The User's avatar did not need to be there for any user page, but it did need to be there for the page we upload the photo on. The solutions we found were large, hack-ey, and difficult to implement, and we thought there had to be another way. There probably is another way, but at the same time, if we spend more time trying to find that way, are we really saving any time? I mean, the solutions we found weren't inefficient, they didn't make unnecessary database queries, or take up a lot of space, they were just difficult to code in and make the code look uglier. In a situation like this one, especially, it's hard to make a call. In production, you might just want to get the thing working and out the door, but in academia, you want to make the cleanest looking code you can since you'll have someone poring over it to find a way to make you lose a couple more points.

I don't really have a decision here, and I don't think there is a decision, really. Different situations warrant different calls.

Wednesday, April 16, 2014

Javascript, can't live with it, can't code without it

Javascript is such an interesting language, in that it's used practically everywhere, near limitless in potential, small filesize, very powerful, and yet still almost universally reviled.

Javascript code looks ugly. It is the exact opposite of "What You See is What You Get" coding. Everything in Javascript is arcane and convoluted. It's more like ancient runes than modern code. Single function calls can be lines upon lines of drilling down the right class. The tags are all over the place in the HTML and the functions like document.ready and all the dollar signs and curly braces everywhere.

And yet, it's absolutely vital for the glue that holds together the HTML, Ruby, and SQL. Without Javascript, web design would be a field reserved only for Spider-Man.

Tuesday, April 15, 2014

More blog posts from now on, also Haskell

I've been neglecting my blog posts for the first half of this semester, but I'm going to do my best to post a new blog post every day from here on out.

Lately, I've been doing research on Haskell libraries and Monads. Most recently, I've discovered the Haskell QuickCheck library which generates random input sets, tests functions, and outputs the results all in a single import and function call.

Needless to say, QuickCheck is incredibly small, easy to use, and powerful, as is the way with Haskell libraries. The library includes the Arbitrary data type, which has many different built-in data structures, as well as a simple API for defining more. The Arbitrary class allows for a set to draw a random sampling from, for example, Arbitrary Int defines a randomGen that returns only integer values, while Arbitrary [a] defines a randomGen that gets lists of any single consistent type of any length. Tests are made by defining a function that takes an Arbitrary and returns a boolean. Haskell's powerful type inference means that an average user doesn't even need to know about the Arbitrary class. If you make a function that takes something and returns a boolean, and feed it to the quickCheck method, it'll fill in that something with an Arbitrary version of it, if one is available.

Like most Haskell libraries, it's not without its headaches. It's a bit tough to install the right version for your purposes, since QuickCheck-2.0 and higher removed the "Batch" module from 1.0, which is very useful for running large number of test suites simultaneously and amalgamating their inputs into one simple line, so instead of "Test #1 succeeded on 100 inputs ... Test #500 succeeded on 100 inputs" you have one line that says "500 tests succeeded on 50000 inputs". Uninstalling the most recent version (which is easy enough to accidentally do, assuming it keeps the proper modules) was a hassle in and of itself, as Haskell's package manager, Cabal, has no way to uninstall packages. To remove the most recent QuickCheck, I had to track down the lib files it download to some random place on my file system, remove them, update Cabal so it forgets that the lib was there, then reinstall the older version with the module I needed.

Sunday, March 9, 2014

Wednesday, February 26, 2014

Ruby on rails - Sweet magic-ey science

I've dabbled in Ruby on Rails for a while, but it didn't really gel until I saw it in action. I was impressed before, but now I'm practically a zealot. Seeing Matt make a website from the ground up in only a few lines of code really demonstrated how well the system works. I'm looking forward to learning this system during the course of this project for my own personal projects.

Sunday, February 16, 2014

My top 5 - CS460 Projects

1. N[_]8R by me
Obviously.

2. Automaton by Luke Balaoro
I love puzzle games, and Turing Machines are interesting enough to make a fun puzzle game.

3. Demigod by Matt Smith
I do like Ruby on Rails, and this project seems well in scope and pretty useful.

4. UNM Visual Scheduling by Dan Green
Hate the current UNM system. Hate. Would love to see it done better.

5. ZombieCraft by Kevin Dilts
What can I say? Zombies are cool.

Tuesday, February 11, 2014

Friday, February 7, 2014

Three Words

Three words I look for in my team members are:

Empathetic
Creative
Focused

Three words I almost considered, but assumed would be expected:
Determined
Talented
Expressive

Another proposal review - Diabe-Tech

https://www.dropbox.com/s/ym0rlcbaer3f0a7/review-diabetech.pdf

Review of project - SmartPaper

https://www.dropbox.com/s/281gi2u6jbr98ge/review-smartpaper.pdf

CS 460 - Project Proposal - N[_]8R

(Originally posted Feb 3, 2014)

https://www.dropbox.com/s/k66o7y580gudusx/Proposal.pdf

Improvements on concept

(Originally posted Jan 31, 2014)

Going over some feedback in class, I feel like I should take stock of a few things I need to keep in mind before my final proposal.

1. Timeline. Mine was terrible, need to fix it.

2. Usability. Need more information on how the website will be used, how it will look, etc.

3. The name. I thought the name was honestly pretty lame, but I couldn’t think about anything else. It’s pretty much Kickstarter but without money involved. A suggestion I got was N[]8R (N-Cube-Eight-R) and that’s pretty good, honestly, I might use that.

4. Abuse of the system. I realize that the problem with the site, especially with the points system for backing projects, can be easily abused for substantial gain. I’ll look into how websites like BoardGameGeek handle their system and make it difficult to game the system.

5. I realize that I’m basically building an unabashed hug-box, but honestly, I think we need that. The Internet’s full of bash websites, why not a place for everyone to try being nice?

Kick-Motivator Timeline

(Originally posted Jan 29, 2014)

Attatched is a PDF of the projected Timeline of Kick-Motivator. The timeline is broken into two major milestones. Milestone 1 is having a functional User Blog for a Project, complete with account management and ownership. Milestone 2 is adding in the community hub, comments, and supporting projects. Milestone 1 is straightforward, but technically advanced, while Milestone 2 will be easy to implement, but will require significantly more design. During the entirety of development, both milestones will be considered during the weekly design meetings (not scheduled, pending team’s availability)

Note the projected Feature Freeze date, at which time no changes are to be made to the design of the website, and all group meetings from then on will be primarily Scrum Meetings to finish large portions of the site together.

Timeline:
https://www.dropbox.com/s/70i75wtekelrrk2/KickMotivator.pdf

Project Proposal CS460 - Kick-Motivator

(Originally posted Jan 26, 2014)

The Internet is a fickle place, forums and social media flocks to content creators, artists, animators, etc., but at the same time, is often so critical of people that those content creators do not want to continue with their ideas. Kick-Motivator is a sort of “emotional crowd-funding” website in the vein of Kickstarter, where users can post their project ideas, rough sketches, early betas, or proposals, and users can choose to support the projects. Many ideas fall flat because creators feel that no one would care if their idea were finished, but Kick-Motivator would provide a healthy environment to raise projects from ideas to reality. Kick-Motivator would be useful for any independent artists, programmers, musicians, or any other content creators who seek support for their creative endeavors. The website would have a built-in currency that users would accrue by completing projects and posting constructive comments voted on by other users. This built-in currency could be pledged to the completion of other projects, or spent to remove ads from the site, and could be purchases for a small fee. The website would also take a small cut from any money donated to the content creators through the website. By supporting this website, you could help hundreds of creators get recognized and know that there are people out there who care what they could contribute to the world.

Software Engineering

(originally posted Jan 24, 2014)

http://en.wikipedia.org/wiki/Software_engineering

Of course, the first thing I noticed reading this is that Computer Scientists are really clever when it comes to acronyms. Coming into this article, I didn't really know there was a difference between Software Engineering and Computer Science, but now I see that SE is what I've been looking for. I’m not a fan of running numbers for the sake of running numbers, honestly, and I feel like half of the discipline is learning things that other people have already discovered. Software Engineering is learning to apply those theories we were taught. I have to wonder why a class like this is so late in the CS curriculum, but I believe I will probably change my tune after seeing how much work there is to be done.

Transferring over from old blog

Over the next weekend, I'll be porting over my old blog posts from my previous work blog. Each post will have an accompanied date showing when they were originally posted. Transferring over to blogger will allow other people to comment much more easily on my blog posts.