Am I Agile enough?

In beginning my job search, I have seen the term Agile thrown around as a selling point on job listings. It got me curious, what is that and why would I be happy about it as a developer? Turns out, its a fantastic way of organizing work-flow and minimizing stress to complete large-scale projects. And Flatiron has been teaching us how to be agile developers all along, Pair-programming, test-driven development, and daily stand-ups are just some of the techniques we are already familiar with.

The founding ideas for Agile can be traced as far back as 1957 when Iterative and incremental software development methods began to be created. by the 1990's there were many versions of this process, such as SCRUM, extreme programming or feature-driven development which each attempted to address ways to make the work happen more efficiently and with better outcomes. Then in 2001 a group of 17 software developers met at a resort in Utah and wrote the Manifesto for Agile Software Development.

The primary values of the method are:

• Individuals and Interactions over processes and tools
• Working Software over comprehensive documentation
• Customer Collaboration over contract negotiation
• Responding to Change over following a plan

Which are expanded upon in their twelve main principles:

1. Customer satisfaction by early and continuous delivery of valuable software
2. Welcome changing requirements, even in late development
3. Working software is delivered frequently (weeks rather than months)
4. Close, daily cooperation between business people and developers
5. Projects are built around motivated individuals, who should be trusted
6. Face-to-face conversation is the best form of communication (co-location)
7. Working software is the primary measure of progress
8. Sustainable development, able to maintain a constant pace
9. Continuous attention to technical excellence and good design
10. Simplicity—the art of maximizing the amount of work not done—is essential
11. Best architectures, requirements, and designs emerge from self-organizing teams
12. Regularly, the team reflects on how to become more effective and adjusts accordingly

These principles lead to a structured workflow that remains consistent with most implementations. iterations, or sprints, are one to four-week timeboxes where the entire team works together to build a functioning app or feature. the measure of success is having working software at the end of each sprint. 

Each team has a product owner that represents the customer or stakeholders to the development team.

An information radiator is a large board visible by the whole team that displays frequently updated progress.

A daily stand-up is held where the team meets to discuss the last day's progress and what they intend to do today. They also discuss any roadblocks they foresee. Problem-solving of those roadblocks should not be done during the stand-up, as it may waste the time of other members of the team not involved with that issue.

Pair programming and test-driven development are used while working on the code. Testing on the product is completed during the build. As opposed to in a waterfall method where a product is completed, then tested.

The scheduling of the overall sprint is done in a "Rolling Wave" fashion, where milestones are set, but dates are left flexible. This is called an Adaptive method, vs a Predictive method where timelines are precisely scheduled, anticipating difficult points in advance. 

Just as when building an app we continue to seek abstracted and dynamic functionality, so does the agile system. Agile isn't just a series of best-practices that can make a project more efficient. In order to be successful the culture of agile needs to be present as well in the company using it. That means the company needs to offer the flexibility needed by the team and if necessary, advocate for them to the client.

There are many offshoots of the agile system, and some companies may pick and choose which aspects of it work for them and use only those. Though it is a popular practice as of now, agile is certainly not the only way of doing things, and there may be others developed in the future that work better. However, I have enjoyed working with the pieces I've been introduced to so far and look forward to trying out more of it!

Resources:

https://www.agilealliance.org/

http://pmdoi.org/

https://en.wikipedia.org/wiki/Agile_software_development

Working with the three.js Library to create 3D objects using JavaScript

I've had a growing curiosity recently in what code makes the Magic of Pixar films happen. They must be using some software to create the beautiful images and characters we all know and love. But who makes sure that software is functioning properly? What Magic is happening behind the scenes? 

After a little digging, I found that they mostly program their software in C or C++, so I'm not quite there yet, but I did find a JavaScript library that offers the ability to create 3D models and objects. So I'm going to dive into the basics of that.

The three.js library was created in 2010 by Ricardo Cabello. It was made with the intention of displaying 3D images in the web browser without a plug-in or standalone application.

It is built on top of the WebGL (Web Graphics Library) API, made for rendering 2D and 3D graphics. three.js is to WebGL similar to what JQuery is to Javascript, syntactic sugar allowing many of the same actions to be performed with less code.

The documentation on three.js is very good and detailed. They walk you through creating your first 3D object line by line. 

The first step was to create a project and saving the three.js files to the directory. Then I created an index.html file and required <script src="three.js/build/three.js"></script>.

Next, within the script tags I included the following code: 

In order to create an animated 3D object, three things are required: A scene, a camera, and a renderer. The Scene is like the environment in which the object is created. The camera is the perspective from which the viewer sees the object and the renderer... well, renders the object to the page.

The scene is a container that defines what will be rendered and where it will be placed.

The camera takes arguments, a field of view, an aspect ratio, and the last two define the boundaries within which the object will be rendered. if the camera is too near the object or far away, it won't render.

The renderer is where things get good! This is where the element is added to the DOM and defined. You set the size, shape, and color of the object using built-in methods. Here you also need to use a mesh to dictate the material that will be applied to the shape that can then be colored, making it visible and movable.

Finally, an animation function is added to make the object appear on the page and move.

Then, I was able to add custom javascript to randomly change the colors on reload. I also adjusted the speed of the animation and shape of the object.

For the following animation, I changed the geometry type to a cone. 

There are many other geometry options including rings, spheres, planes and even text. It's also possible to add lighting effects to the object so that objects like spheres will have dimension and not appear as a flat circle. 

Any Questions?