Sunday, November 19, 2017

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






Wednesday, November 1, 2017

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?

Monday, October 9, 2017

Ruby vs. JavaScript




This week I begin really diving into JavaScript. I had studied a bit of the basics in Flatiron's Bootcamp prep course. but now that I understand how to work with Ruby, that feels distant. Over the weekend we had a bit of a refresher course in the homework, but there were several new concepts introduced as well. The entire time I found myself comparing what I now know about Ruby to what I was learning about JavaScript. Here are a few of the concepts that stood out to me.

Assignment and Comparison

In ruby = is used for assignment. It is used to set a variable. In Javascript this is the same. The real difference comes with the comparison operators. In Ruby we use the == to compare two values and return true if they evaluate to exactly the same. In Javascript the == is a non-strict way of doing this, which means if the type of the value on one side is not the same as on the other, JS will try to convert one so that they match. In JS it is more reliable to use === to compare two values since this version is strict, meaning it checks the equality of each value as well as the type, and if the type of the values doesn't match, it will return false. 

Objects

In Ruby, everything is an object. In JavaScript, an object is set to a variable and written as a hash. In both languages, a hash is a way of organizing key/value pairs. The Ruby objects are written slightly different as well (lots more semicolons!).The keys and values are both strings, Whereas in Ruby the keys would be symbols.



In JavaScript objects it seems we don't need to initialize them with a method the same way as in Ruby classes. They are initialized within a function with Object.create() or new Object() to create a new instance and set key/value pairs.  

Self and This

In Ruby we became very familiar with tracing the value of self when referring to multiple objects. It was used to refer to the current object that 'owns' the code currently running. That means within the class, it can refer to the class as a whole, or it can refer to a single instance of the class. 
The JavaScript equivalent to self is this. The keyword this,  when inside a function that creates an object, holds a reference to the most recent object initialized.


Prototype and Class
Every object in JavaScript inherits it's properties from a prototype. It seems at first glance that a prototype is equivalent to a super class in Ruby. However, they are rather different.  The JavaScript prototype is an object itself, and it is able to manipulate, describe or implement other objects. These abilities are the definition of a metaobject, which both Ruby classes and prototypes are. So whats the difference? Prototypes are a lot less private, the prototype is available to be used by many objects.  They are able to be chained together, each object inheriting methods and properties from the prototype before it. The Ruby object cannot store methods, but classes can. The Javascript method can store methods.


Hopefully this leaves you slightly less confused than I was this weekend!

Monday, September 18, 2017

Method Madness

While learning to code, enumerable methods have proven themselves time and again to be invaluable. Often I will find myself writing 5-6 lines of code for a method and realizing it could have all been completed by a simple, one or two word method. Im going to explore how some of them that might not be as well known, at least I haven't used them often yet. 

.all?
This enumerable method takes a block and for each object passed in, assesses if it is true or false. If all the objects are true the return value will be true. If even one of the objects returns false or nil, the method will return false. If no block is given .all? provides one that would read {|object| object} so that it can look at each element in the array or hash being acted upon.

given the following code:

Here we see that the arrays that have any odd number in them return false, but the array with only evens included returns true!


.each_with_object

the .each_with_object enumerable method is a bit complicated to understand and the ruby documentation includes only a short description of what this elusive method can do. 
If you want to solve a problem like the one below in which we would like to return a hash where the key is the original object and the value is the new object after being acted on by the block.

.each_with_object offers a way to do this without sandwiching 


The tricky bit for this method is that it returns the original object given, just as .each does. 

I believe what this means is that the original value is not altered by the method, it stays the same, but is used to create a new object based on the original and the block. The output can include both of these objects.


.take / .take_while
These two methods are somewhat specific, but can certainly be useful to know of!  The .take method is given an argument of a fixnum and then will take that number of elements from the start of the enumerable that the method is called on.

The .take_while method takes a block and evaluates if the return value is true or false. Once it hits a false value it stops iterating over the element and will return all the elements from the enumerator that came before the false.


Tuesday, September 5, 2017

Youtube from scratch


I have been really struggling with learning to manipulate Object Relationships in Ruby.  Wrapping my mind around the logic that follows from one class to another remains tricky through as many number of times as I have practiced it. Still, I know it is super important and will be used throughout the rest of the course at Flatiron School and beyond. So I have continued to find new ways of practicing building classes and mapping these relationships. This week I decided to create my own project by modeling the domain of Youtube. 

The website used by millions of people to replace the void left in our lives after Americas Funniest Home Videos went off the air. 



I began making the model using the three classes: Poster (someone who makes a video and posts it), Viewer, and Video. I initialized the Poster and Viewer with usernames and the Video with a title.  I knew the Video would need to know who posted it and be able to find out who was watching it, so I added poster and viewer to the Video class. Then I could begin writing methods!

I wrote the basics, a method to collect all the Viewers, all the Videos, all the Posters.  A method that allows the Poster to post a video and allows them to know who the viewers are of their videos. 
But once I began writing a method that would tell which videos a user has watched, and then one to count how many times a user has watched each video (cause we all know we have those videos we can watch over and over...)

When trying to write these methods however, it seemed like something was missing. I just couldn't seem to get them to work with the setup how it was. so I re-examined my model and found that I was indeed missing something that could make everything else fit together. Instead of just using the Video class as the through class, I needed to add a Watch class to create instances of a viewer watching a video and collect those instances to be counted and examined in other class' methods. Once I created this fourth class I had a model unlike anything I'd worked with before.  Could I really have a has-many-has-many-through model? Would the poster still be able to understand who the viewers are though that extra layer? 



Its totally possible!



By using the Video and Watch classes both as through classes I was able to write methods that could relate to them all. The Poster was able to collect the usernames of the viewers.


The Video class has methods that can count the number of views for each video and collect the usernames of the viewers.


And the Viewer class is able to collect a list of all the watched videos. Produce a count of how many times each video has been watched and then output the viewer's favorite video based on the video that has been watched the most. 



The hardest part of this model was writing these last three methods. all_watched_videos required looping through an instance twice in order to return only each video's title. The watch_count method required creating a new hash and placing each video into key-value pairs within that hash and then incrementing a key's value each time another instance of the same video was encountered in the all_watched_videos array. Then favorite_video required iterating over the hash from watch_count and putting the title, found in the key of the hash, which has the highest value.
If I were to continue working on this, I would like to add a comments class, and add methods where a viewer could leave a comment, and a Poster could respond to a comment.

This project may have become bigger and trickier than I expected, but it taught me a lot about object relationships. 


Thursday, August 17, 2017

Coding with Friends

Working on the pre-work for Flatiron School was a lonely experience. Working from home to begin a learning a new skill was something I had done many times before. However this time I felt like I had so many more questions and frustrations with the process. Sure, I could ask questions through the Learn website. This was sometimes helpful and also began to connect me with my classmates, but it was slightly intimidating to do so. I needed to sort out what those questions even were, then how to word them so that someone else would understand. I think I ended up only asking 2 questions through the entire process.


All this changed once we got into the classroom. That is when I discovered the power learning together can have. For even the smallest question or confusion I could suddenly turn to the person  next to me and say "do you get this?' Every time, this was met with either "Yes, here's what you're not seeing" or "No, lets figure it out together." The learning process instatnly became collaborative. 


"Students learn a great deal by explaining their ideas to others and by participating in activities in which they can learn from their peers. They develop skills in organizing and planning learning activities, working collaboratively with others, giving and receiving feedback and evaluating their own learning." - From - Peer Learning in Higher Education: Learning From & With Each Other

There have been several studies evaluating the effectiveness of learning with others who are at the same level, as well as at varying levels of learning. Each style was found to be valuable in its own way. At Flatiron school I have also found this to be true. When approaching a new subject along side someone who is also unfamiliar with it, we each see the information in different ways and then work together to understand how both the perspectives are valid. When working with someone who is a peer but has already mastered the subject I can trust that their perspective on the subject works to provide the desired results. 

"The results of this study also suggest that peer-assisted learning increases confidence; reduce anxiety and stress and effect on development of learner’s future responsibilities." - From - Evaluation of the efficacy of peer-learning method in nutrition students of Shiraz University of Medical Sciences
A phrase I have heard many times since classes began is "by teaching you, I solidified the concept for myself." This is a technique used often in education. By teaching others, you teach yourself. Often when working to find a way of demonstrating or explaining an concept, just the act of figuring out how to do that will force you to re-examine the material and you gain a deeper understanding of it. 

So we know that peer learning works. However, we cant all be so lucky as I am right now to be surrounded by others learning with me. What do we do when that happens? how can I learn anything once school is over? Or if I'm working on material at home alone?  

Thats were the magic of Rubber Duck Debugging comes in!


Sometimes, I will ask someone a question and just in the process of asking and explaining my problem I discover the solution. The Rubber Duck method is based on this. A programmer will explain the code and an issue, out loud, to a duck. By explaining what the code is supposed to do and then observing what it actually does, the divide can be seen more clearly and the problem is found. Ultimately they are just explaining the issue back to themselves, but it works! 


 Sometimes your mind can become so enveloped in the code that you cant see the big picture. The Rubber Duck method helps you to pull back the perspective.



By combining these two methods of learning, peer and Rubber Duck, I believe the process is made far easier as well as more effective. 

Happy learning!






Peer Learning in Higher Education: Learning From & With Each Other, edited by David Boud, Ruth Cohen & Jane Sampson. Published by Kogan Page Limited 120 Pentonville Road, London N1 9JN, UK and Stylus Publishing Inc. 22883 Quicksilver Drive Sterling, VA 20166-2012, USA. http://www.styluspub.com/ Copyright © David Boud, Ruth Cohen, Jane Sampson and individual contributors, 2002.

MOHAMMAD REZA DEHGHANI, MITRA AMINI, JAVAD KOJURI, PARISA NABEIEI
J Adv Med Educ Prof. 2014 Apr; 2(2): 71–76.