RubySlippers

I found out while doing my app that visual demonstrations of data can be extremely effective.  After viewing a presentation at Flatiron presents and speaking with my instructor,  I was swayed to try out ChartKick. 

ChartKick is a plugin that works with Rails to create visual charts. If you do not want to use the plugin with Rails you have the option to opt out and you can instead use the Javascript version. With this plugin you can create various charts to display statistics. The various types of charts include:

1.Line charts

2. Pie charts

3.Bar charts

4.Geo charts 

ChartKick prides its self in the fact that you can create a chart utilizing one line of ruby. That’s usually not the case if you would like a chart with added functionality or if you choose to customize its appearance. 

How To Use It

1. Add the Gem file and its additional helper gems that help when dealing with data. 

As we’re making our way through Rails land, I have manage to hit many walls when it comes to trying to figure my way around. In order to help make things easier on my self I have tried to create an environment that reduces the potential for small and silly errors and instead helps in increasing efficiency.  As I googled for ways to get the most out of Rails I stumbled upon these two built in resources that Rails provides. 

Pretend Generate

In the beginning of my Rails journey I always managed to make errors when it came to generating either migrations , scaffolding and/or migrations. To help ease this misery this caused me I started to instead run pretend! I found that sometimes the generate could create or modify multiple files that I may not want to. If I need to find out what files will be created/modified, I simply run a pretend migration: 

code :

rails generate model Blog -p

If you’re not sure what files a Rails Generator would create for you, just add the -p option (or --pretend) for a dry run.

Rake notes 

This is super useful for me since I have ocd and I need to know what I have to do at all times. I usually find that since I’m still learning when I leave to go home maybe just for lunch and I interrupt my working session for these breaks, I can sometimes loose my footing. To help with this I started using Rake Notes. 

Rails provide rake notes, which will show the list of the comments that begins with these strings: 

#TODO, #FIXME, #OPTIMIZE

Rake notes by default only shows notes for OPTIMIZE, FIXME and TODO

But if you are into customization and have the time you can always create your own by adding or defining rake notes which is simple.

So we have finally been introduced to old blue eyes aka Sinatra ! We are now on our way towards building more complex apps... YAAAH!! With that said I realized early on that there was something pretty annoying with the entire process. If I had to make a change, I would have to stop and restart the server. So in order to save myself the hassle of constantly having to stop & start the server I began using the Shotgun gem. 

In the terminal, I  would proceed to start up the server by typing ruby basics.rb.

From there we would go to http://localhost:4567/ in the browser and you would see my message:

But lets say that I wanted to make a change ! After a change you would normally have to restart your sever and if you did not restart the server, then you would get hit with the page below which I’m sure some of us may already be familiar with :

Well this all sucks !! But there’s another way. Like with many things in programming there is always an alternate way of going about things. On my search for a better path I came across the Shotgun gem! Shotgun will reload your application every time a new request comes in from the web browser.

How does Shotgun work, how do you install it and how do you run it?

Shotgun is said to be an “automatic reloading version of the rackup command that's shipped with Rack. It can be used as an alternative to the complex reloading logic provided by web frameworks or in environments that don't support application reloading.The result is clean, application-wide reloading of all source files and templates on each request.”  https://github.com/rtomayko/shotgun

Installing the gem is be pretty self explanatory. In terminal type in :

gem install shotgun

Now you can go back and make changes to your app. Once you’re done, if you are in a current Sinatra server that did not begin with the use of the Shotgun gem, here is your opportunity to escape (CRTL-C).  

Next you can run shotgun name_of_your_file.rb and Shotgun will automatically restart the server every time you refresh the page!! 

This is useful when you’re doing a lot of development work, but as the entire application is being restarted, it can be slow.

Now, without shutting the server down you can make any changes that you want to your application. They'll be displayed automatically in any future requests you make to the server. 

There are also many other great options that may come in handy. To explore these options simply type in terminal shotgun --help.

Two of the options I would like to highlight are : 

shotgun file_name.rb -d, debugging: which outputs extra debugging information. I’m sure this could will be useful if something goes wrong but I have yet to use this. 

-O, browser: which immediately opens up the browser after starting. 

Now go out guns blazing on these labs !! 

If you’re talking to your friend or a significant other and you want a sandwich, you don’t typically give them step-by-step instructions on how to make the sandwich. If you did, it would feel like programming your friend. Instead, you’re far more likely to talk about the result you want, such as “Please make me a sandwich” (or, perhaps, “Sudo make me a sandwich”). If your friend is willing and able to follow this instruction, then they would translate the phrase “Make me a sandwich” into a series of steps, such as finding a loaf of bread, removing two slices, applying toppings, etc.This type of result-focused instruction is how declarative programming works.

SQL is declarative

In SQL you "just" declare the nature of the results that you would like to get. Not how your computer shall compute those results. You're telling the "machine" what you would like to happen, and allowing the computer to figure out how to do it. It is the role of the query interpreter (SQL is a language so you can infer what an interpreter is) of the database system to design and perform a process to produce such a result. The problem is that most of us intuitively think in terms of imperative programming.  As in: "machine, do this, and then do that, but before, run a check and fail if this-and-that". This includes storing temporary results in variables, writing loops, iterating, calling functions, etc. Forget about all that. Think about how to declare things. Not about how to tell the machine to compute things.

Benefits

SQL is shorter and easier to read. Since we don't have to deal with the how we can focus on what and let the database optimize the how for us.

I'm So Aggravated by  Aggregate Data!

In statistics, aggregate data is data combined from several measurements. When data is aggregated, groups of observations are replaced with summary statistics based on those observations.  For example:

wizards| id | name | age | color | power_1 | power_2 | power_3

powers name | damage | wizard_id | ---------------------------------------| fire ball      |    7   |     1     || ice storm      |   13   |     3     | | shape shift    |    0   |     4     | | invisiblity    |    0   |     2     | | lightning bolt |   23   |     1     | | earth quake    |   15   |     2     | | tidal wave     |   44   |     4     | | teleport       |    0   |     3     | ---------------------------------------

We aggregate data using aggregate functions which operate on a group of values to produce a single, summarizing value. So it would require taking summary observations, in this case wizard powers and doing something with that information. Aggregate functions operate on a group of values to produce a single, summarizing value. We can now find the average, count or sum, along with other information. 

Something I learned  through trial and error are some of the things that an aggregate expression can't do! 

It can’t appear in a WHERE clause. For example :

If you want to find the title of the book with the highest sales, you can’t use:

SELECT title_id  FROM titles WHERE sales = MAX(sales); YOU CAN'T DO THIS!

Also you can’t mix nonaggregate (row-by-row) and aggregate expressions in a SELECT clause. A SELECT clause must contain either all nonaggregate expressions or all aggregate expressions. 

If you want to find the title of the book with the highest sales, you can’t use:

SELECT title_id, MAX(sales)FROM titles;              --Illegal DON'T DO IT!

You may think you're slick and try nesting functions. Nope! As much of a short cut as this may seem, you can't nest aggregate functions either !!

SELECT SUM(AVG(sales))FROM titles;              --Illegal

Yet with all of this the use of aggregate data dramatically reduces the time to query large sets of data. So there's your take away !!

This week at Flatiron we were given the opportunity to finally put all of our knowledge to use in a project that required us to create a Command Line Interface App. After just shy of six weeks we have learned basic ruby technics and have continued to build on this. All of this has lead to ability to be able to implement this knowledge into a functional command line app. 

In the project we had to integrate three classes

Second, we had to fetch data. In my case, my partner and used a chrome extension I found called Kimono. Its in beta and requires you to sign up in order to retrieve your api once you have created it. 

To create a kimono API from any webpage, navigate to the web site you want to get data from and click the kimonify bookmarklet. This will bring up the kimono toolbar.

To get data from the page, simply click on it. Each time you click on something new, kimono will add that element to your dataset, and also will suggest similar items. After you've made all your selections and named your datatypes and collections, you can preview your data by clicking the  <> button. Data can be viewed or downloaded in JSON, CSV or RSS. When you're done click the done button and name your api and that's it. From there the possible ways you can use and tweak your api are endless. 

With integrating kimono into our project it gave us more control with items such as making api calls which we were able to control since we created the api. 

Upon hearing that I was accepted into the Flatiron Web Development Fellowship I was extremely ecstatic. I knew my life would ultimately change forever. Yet as the excitement settled down I began to do what I usually do; I thought about all the possible obstacles this journey would bring about. I knew that I was in a great position and that this opportunity was one in a million. But I still contemplated whether others would see it the same way. I thought about how I was entering into a space where I would have to deal with my fears head on. I was looking way beyond my time at Flatiron and grasping with the notion that once Flatiron sent me out into the world, would I be ready for all that lied ahead of me?

This may seem obscure as I had not even stepped foot inside of my Flatiron classroom but I like to emotionally prepare myself. It helps me deal with possible situations that may or may not arise. I realized that for most of my life I dealt with barriers that were not of my own choosing. I’m a black Latina female who spent most of her life being the only one of kind in most situations. This has never bothered me. Yet these situations just happened. I never really went into a situation knowing that I would be throwing myself into “fire”. The idea of knowing and being aware can be difficult to overcome. Its extremely scary, so scary that it can hinder you from moving forward. In order to prevent this from happening I had to realize what it was that I was fearful of. They say acknowledgment is the first step towards getting past any obstacle!

Would I be good enough?! This was a question that held a place in my mind since the day I filled out my application for Flatiron. I trust Flatiron literally with my life, but could the world trust a girl who, just a few months ago, never knew what RegEx was?! Could they trust that I could get the job done even though I never achieved a degree in some form of technology! A girl who only worked in tech as an events planner!? This was hard to swallow. Would I be taken seriously? Just thinking about it now makes me want to go under my sheets and hide!!

Luckily I live with my boyfriend who is also in the tech space and has prepared me for what I could possibly experience in more ways than he or I could have imagined. My boyfriend is the typical “tech guy”. He works at a start up in the city, wears tee shirts, jeans and sneakers everyday to work, rides his bike when the weather permits, uses jargon like “crushing the game”, but most importantly he’s a white, male who grew up in a upper middle class household and has a terminal masters degree in design. Upon telling him that I was interested in getting back into tech as a programmer, the first thing he said to me is that I better be prepared to change the way I dress but that I would be okay otherwise because my interest aligned with that of a typical programmer. After hearing this I was taken back with this comment and immediately responded with a “are you serious?”. He was. It was at this instance that I realized what challenges would lie ahead. I was about to enter what sounded like a frat club that I was going to have a hard time being inducted into because I was the wrong gender and talked and looked different. That was the day I accepted my entry into Flatiron.

One might ask why am I doing this then? If its so scary and causing me so much stress, why would I put myself through this ? Why did I say yes to this crazy path? Well the most obvious is that I want to be a Programmer! But everything that comes with it is probably more important to me. What it would mean for someone like me to become a Programmer speaks volumes to what can be achieved when given a chance and taking it by the helm. Being apart of this fellowship and entering into the space of technology is something that I don’t take lightly.I know that this is bigger than me. I’m ultimately paving the way for individuals like my little sister, who wants to be an engineer. When I get caught up with feelings of fear and worry about being respected and having to prove my worth, I reflect and acknowledge that I am doing this so that my sister and others like myself will hopefully never have to feel this way.

I can’t speak for the hearts of everyone and I won’t be naive and say that there are not those with ill intentions out there. I know that there may be those who don’t believe in me and my peers but to combat that, the best thing we can do is program our asses off and take all the tools we learn and show the world that how we got here; even though it may be drastically different and untraditional, shouldn’t matter !! It should be about what we have to offer the tech community. Our skills and different backgrounds that will help diversify this space and diversity only helps to make things better.

As a newbie to the world of programming I am always trying to figure out various ways to implement what I have learned. I find that I retain information and concepts better when I utilize them in my everyday life. I find that I struggle the most with the notion of thinking " like a programmer".  I've been reflecting on this idea and how I could apply it to my own life . After reading many pieces on the contributions programming can offer to your life, I walked away feeling reenergized. I wanted to share this with all of you in hopes that it could be of some benefit to someone else. 

1) Solving Problems! Duh!

The first thing we must do after we sit down at our laptops and evaluate the task at hand is to figure out what is the problem that needs to be solved. Problem definition is a very useful skill both in and out of programming. Defining where a problem begins and ends can be applied to basically everything we. Defining your problems before tackling them improves the quality of your decision-making enormously.

2) Thinking critically and creatively.

From working with each other, researching on the internet or reviewing labs with our instructors it should become quite evident that in programming there are so many different ways to go about solving a task. In order to come up with these various solutions, whether we know it or not it takes creativity. Programming is rare in the sense that it takes creativity, logic and being able to think outside of a problem. In order to allow this to happen we may at times need to step away from our work in order to be able to clearly point out obvious flaws. This could certainly be applied to many other areas of our life. When issues or problems come up, I stop and think about how to solve them instead of just jumping in. I also don't give up as easily when trying to fix a problem.

3) Don't assume. 

Computers are dumb... that is until we step in. Computers become useful when they receive some instructions, and ‘smart’ when they receive amazing instructions from smart humans.They’ll try to do exactly what you tell them do regardless of whether or not they can do it and they don’t really handle failure very well. This is because they don’t know anything about what you’re trying to do until you tell them explicitly. Having to provide this level of instructions is rare in the real world unless you deal with animals and babies. Learning that assumptions are bad is great. You really can apply this anywhere. Everybody is guilty of making mistakes based on incorrect assumption. The less that we do it, the better for all of us!!

4) Paying attention. 

Some more than others might know that misplacing a comma is capable of destroying your happiness for an entire day. Attention to detail is crucial when writing code!! Attention to detail is an obvious prerequisite for doing better at life. Make your life easier by realizing that the little things count. 

The take away. 

A lot of this probably sounds pretty obvious, and it is, but these are just a few ways to demonstrate that there is more to writing code than meets the eye. Thinking like a programmer can only lead to great thinks like becoming a more logical, efficient and analytical person as well as improving the quality of your decision making in the long run. Programming teaches you that you build things step by step. And that advantages occur, like in life, from a series of minor advances. Now go out and be great !!

In response to David Blaine’s Ted Talk:

http://www.ted.com/talks/david_blaine_how_i_held_my_breath_for_17_min?language=en#t-848435

So my dream has always been to have powers. Like most I have pondered over what superpower I would love to have. That power of course would be control of the mind (telekinesis) like Professor Xavier of the X-men. Unfortunately I live in a world where I can't inject my thought into another person's mind !! Bummer!! Yet there is still hope for me! I can in a way control a mind. The most important mind there is, my own!! Yet I have not fully evolved yet to come to a place where I am able to do this on a daily basis. This leads me to the topic of limiting beliefs. Limiting beliefs that are present in my life have a lot to do with the idea of what others may think about me. Whether these ideas may be true or false does not matter. Growing up in a household where one was taught to not express your feelings as they were said to be of no importance, as well as constantly being judged and held accountable for things that were either outrageous or out of my control has fostered in me feelings of both mistrust towards society, and of those who have not been brought into my carefully picked circle of confidants. With that said, this belief I hold toward others has in many ways stifled my ability to fully enjoy many experiences that life as thrown my way, as I am always worried and over thinking situations. 

Time and surrounding myself with positivity has helped in ridding myself of such notions. The most beneficial route I could take would be one of which I change my way of thinking. At the end of the day I can not control someone else’s thoughts and actions but I can certainly control my own. I am a believer of the power of the human mind and the effects it can have on your way of living and outlook on life. Being able to confront my limiting beliefs everyday in the form of being here at the Flatiron Web development fellowship program has only helped aide me in my journey of release from this constraint. Each day is a step towards becoming a better me. 

Do programmers leave fingerprints in their source code? Do each of us as programmers have a distinctive “coding style”?

As a newbie programmer I don't find myself thinking too much about how my code is a representation of myself. I do find myself trying to solve problems as quickly and as efficiently as possible. Yet on Monday I came across an article entitled "Your coding style can give you away", that has brought this notion to the forefront. The article covered the subject of there being new research that now shows that a developer’s coding style is a type of fingerprint, which can be used to identify who wrote a piece of code with a high degree of accuracy.

Coding style is how your code looks. Coding style is extremely personal and everyone has their own preferred style. You can start to discover your own personal style by looking back over code that you’ve written when you first started out in programming. Everyone has their own style because of the way they learned to code. Coding style is found to be more well defined through solving harder problems. This might indicate that as programmers become more advanced, they build a stronger coding style compared to newbies. 

Researchers from Drexel University, the University of Maryland,the University of Goettingen, and Princeton have developed a “code stylometry,which uses natural language processing( a field of computer science, artificial intelligence, and linguistics that is concerned with the interactions between computers and human languages ) and machine learning to determine the authors of source code based on coding style. The development of stylometry could be used to determine the true author of an important piece of code. For example it could be used to help identify the creator of code of malicious source code aka potential security risk. 

I found this reading to be both interesting and relevant because as new programmers, you have the chance to create your identity. All those comments, spacing usage, CamelCase vs. snake_case , along with many other distinguishable elements are all things that make up your "fingerprint".  For some, your style may come naturally, for others you may decide exactly how you want to go about shaping your identity. At the end of the day just remember, your code is your fingerprint!! 

If you would like to read the article click on the link below:

This blog pertaining to optimism certainly relates to this semester on so many levels such as something as simple as dealing with one another on a personal level, when working in groups with one another, or reviewing each others work or in discussions and debates. It can apply to how we view ourselves and/ or our own work. How we approach each task that we are given and the learning process.