Today, while I was trying to find out why my coffeescript files weren't running on a Rails project, I had the wonderful opportunity to just dig in and read through wonderful documentation on the Asset Pipeline.
It's incredibly helpful and informative, because it made me understand how exactly Rails will percieve the Assets folder that is so crucial to a lot of our projects. In particular, how it reads into the folders, how to customise it, how to specify which asset to use in your html.erb files and more.
Definitely worth my time. Who knows, it might help me figure out -why- my coffee.js isn't being read, it might not - but all the same, the knowledge is crucial.
Also: HAPPY NEW YEAR!
Wednesday 31 December 2014
Monday 13 October 2014
Venturing into Node
The last week, I've been digging into a few codeschool tutorials on node. Node is, from what I gather, rapidly gaining popularity (if it hasn't already), and has some tremendous capabilities. In particular, it is very fast, and I hear astounding news from people that say it's about as close to just parsing code in C speeds as you can get.
That's pretty impressive, when considered. That said, It was a choice between Node or Angular.js (Or perhaps even Ember, or Meteor), but I decided to go for Node first.
Installing it was fairly easy, and the tutorials introduced me to Express, Socket.io, and a new database record (with some -very- simple setup and commands!), Redis.
I'll be putting up some code down here as I get more and more into it, for the time being the syntax and getting over the incredible amount of braces used in node still kind of throws me off, but I'm getting the hang of it.
That's pretty impressive, when considered. That said, It was a choice between Node or Angular.js (Or perhaps even Ember, or Meteor), but I decided to go for Node first.
Installing it was fairly easy, and the tutorials introduced me to Express, Socket.io, and a new database record (with some -very- simple setup and commands!), Redis.
I'll be putting up some code down here as I get more and more into it, for the time being the syntax and getting over the incredible amount of braces used in node still kind of throws me off, but I'm getting the hang of it.
Thursday 2 October 2014
Making Highcharts Series from ActiveRecord items
Following up on the previous blog, where we successfully linked categories on the X-Axis with an Active Record table, we'll move on to the next step, that is actually taking data to be used and displayed on the Y-Axis.
But first, a few things:
The method I described the other day to iterate through all ethercraft names in our controller is actually not necessary. Someone (thank you!) pointed out to me that a method does exactly what I was doing already: .pluck.
So instead of above, in the controller action where this method was called I just did:
And I can safely remove this method and all.
Next, we'll need to make sure we can actually get data for our series. In the previous example, we used a census to obtain the number of people practicing a certain ethercraft by country. So, we'd need to make sure that we can link countries generated via ActiveRecord in case we add/remove more countries.
Let's change this a little (because I already have Race set up as a selection for characters) and make our graph just draw a census of number of ethercraft practitioners by race. We just need to make a race table, along with the associated actions to add/edit races in the app with the actions, and it'll be fairly similar and ready like ethercrafts.
Now, the challenge next is finding the data we need to actually add the series and have actual values for the graph itself.
If you recall the format for generating series in highcharts:
The series itself is expecting:
race that has data for how many of that race practice an ethercraft.
But since we live in an era of databases and charts and linked information pulled from repositories, we'll generate that data ourself.
In this sandbox app, a fantasy character generator, I've got characters, and each character has a race, and an ethercraft. To make this data count work, I'll link characters to their race and ethercraft choice in ActiveRecord via foreign keys. Each character belongs_to one race and belongs_to an ethercraft.
Once that was done, the next step was very simple: to generate the series, we'll just need to add to our controller a new method that'll iterate through characters, iterating each ethercraft for each race.
This method, defined in the controller will take all races and ethercrafts and iterate through each ethercraft for each race, finding characters that meet the current race/ethercraft combination. The glory of map is that, when used in this way, it generates an array the way we want it to. It creates an array for the counts for ethercrafts in order of their id, and fixes them into the race_ethercraft array for each race. At the end of the ethercraft map, it makes a hash taking the current race's name and the array generated for a data key, then that is automatically added into an array for the results for mapping the races. Once that's all done, we'll have every race with a hash that has the numbers we're looking for.
Now all that's left is to fix up our HTML and our AJAX file:
AJAX:
And we'll boot up our chart again:
Presto! Of course, this was made after I quickly rigged up a bunch of characters in the database, and even then - it still looks empty. But if you had real data to add from a database, this would be one way to do it.
The issue arises, that I can think of is in how that method was written: assuming I had a lot of data to go through, would the chart load as quickly? One way to find out is to actually get a lot of stock data. And that's something I'll look into for next time.
Hope this helps, and as always, comments and critiques are appreciated!
But first, a few things:
The method I described the other day to iterate through all ethercraft names in our controller is actually not necessary. Someone (thank you!) pointed out to me that a method does exactly what I was doing already: .pluck.
So instead of above, in the controller action where this method was called I just did:
@ethercrafts = Ethercraft.pluck(:name)
And I can safely remove this method and all.
Next, we'll need to make sure we can actually get data for our series. In the previous example, we used a census to obtain the number of people practicing a certain ethercraft by country. So, we'd need to make sure that we can link countries generated via ActiveRecord in case we add/remove more countries.
Let's change this a little (because I already have Race set up as a selection for characters) and make our graph just draw a census of number of ethercraft practitioners by race. We just need to make a race table, along with the associated actions to add/edit races in the app with the actions, and it'll be fairly similar and ready like ethercrafts.
Now, the challenge next is finding the data we need to actually add the series and have actual values for the graph itself.
If you recall the format for generating series in highcharts:
The series itself is expecting:
- An array, that contains
- hashes for each series, with each containing key/value pairs of
- a name for the series, and
- data, which contains
- an array that contains counts for each category on the graph
race that has data for how many of that race practice an ethercraft.
But since we live in an era of databases and charts and linked information pulled from repositories, we'll generate that data ourself.
In this sandbox app, a fantasy character generator, I've got characters, and each character has a race, and an ethercraft. To make this data count work, I'll link characters to their race and ethercraft choice in ActiveRecord via foreign keys. Each character belongs_to one race and belongs_to an ethercraft.
Once that was done, the next step was very simple: to generate the series, we'll just need to add to our controller a new method that'll iterate through characters, iterating each ethercraft for each race.
This method, defined in the controller will take all races and ethercrafts and iterate through each ethercraft for each race, finding characters that meet the current race/ethercraft combination. The glory of map is that, when used in this way, it generates an array the way we want it to. It creates an array for the counts for ethercrafts in order of their id, and fixes them into the race_ethercraft array for each race. At the end of the ethercraft map, it makes a hash taking the current race's name and the array generated for a data key, then that is automatically added into an array for the results for mapping the races. Once that's all done, we'll have every race with a hash that has the numbers we're looking for.
Now all that's left is to fix up our HTML and our AJAX file:
AJAX:
And we'll boot up our chart again:
Presto! Of course, this was made after I quickly rigged up a bunch of characters in the database, and even then - it still looks empty. But if you had real data to add from a database, this would be one way to do it.
The issue arises, that I can think of is in how that method was written: assuming I had a lot of data to go through, would the chart load as quickly? One way to find out is to actually get a lot of stock data. And that's something I'll look into for next time.
Hope this helps, and as always, comments and critiques are appreciated!
Tuesday 30 September 2014
Passing raw array variables from Rails to JS to HTML
I was working on highcharts to follow my previous blogpost, and I got the chart to work. That's great, but highcharts is incredibly flexible and has a lot of features one can use to create dynamic and interesting charts.
But to actually get there, I need some data beyond static example data of John and Jane eating fruits. So, I worked on passing PSQL database objects into the AJAX file in Rails, so that I could apply the variables I want into the chart. How and why would someone do this? It's fairly obvious why, but an example would illustrate things a bit better.
The chart is merely an example; there's many situations where one would want to transfer a database item, or value, or anything into their AJAX file, but that's moving things from Ruby to ERB to JS to HTML. The core issue to keep in mind is to keep the object being passed around readable all the way.
In this case, we'll make a chart that depicts a census of people with different jobs in different countries. In this fantasy fiction world, we'll call them ethercrafts to describe how they cast their magic spells in their day to day. There are 2 countries in this example, Zahnheim and Rogalia. The end result is to look like this:
There's 5 different ethercrafts in the chart: Soulreaving, Enforcing, Invoking, Evoking and Empty. The bar graph (admittedly, not the best chart type to describe population, but it'll suit this blogpost) will compare the two countries' populations for each type of ethercraft.
For this post, we'll focus on the X-Axis descriptors, the ethercrafts. Currently, it describes those by the following code in the Highcharts javascript in the ajax file:
Going down the script:
The first variable, ethercrafts is a list of the ethercrafts as strings in an array which will be the xAxis categories, (we'll talk about this further down). Next is an array to describe the countries that will be the series in the graph. Each country is listed, along with the population of people with a certain ethercraft described in magic constant numbers. We don't want magic numbers, but for the time being, those will work for this example - country population variables will come next time as I make progress on highcharts.
Next variable is the options that we'll pass into the chart we want to make. Highcharts lets you name this anything you want, as this variable will just contain a lot of data which will be passed in as an argument for the Chart function which expects its options. The options include where it's being rendered to (in this case, an HTML object with the ID 'container') and the type of chart, which is bar, the title of the chart, what the categories in the xAxis is (which is our ethercrafts variable, where it expects an array), and the yAxis, where we describe the numbers as population in thousands. Lastly, we describe the series - which expects an array, along with the relevant data. It passes in the countries variable from before.
Lastly, we have the last variable which is a function to create a new highcharts chart with our options passed in as the first argument.
We'll focus on the ethercraft variable here. Right now, this is what we have for ethercrafts in the AJAX file:
But these are all constants. What if (and we have) an Ethercraft class in our ActiveRecord, which also describes these 5 currently and would like to use that? Imagine if there's more than just 5 ethercrafts, like how there's more than 5 different genres of music and we wanted the graph to reflect that?
We'll first need to get all the ethercrafts in ActiveRecord first, and present it as an array of the names of Ethercrafts. Otherwise, we'll just have an ActiveRecord Relation object that describes all the items or the Object References to the Ethercraft items, or worse.
Firstly, in the controller where the graph will be displayed, we can use the following private method and store it in a single instance variable, such as @ethercrafts:
With that done, next we'll need to change the variable in our AJAX file to take in the collection of the different types of Ethercrafts from ActiveRecord (via our instance variable, @ethercrafts). To do that, we can go to our application.html.erb, and add in our header:
Then we should change the ethercrafts reference in the AJAX file and point it to window.ETHERCRAFT. And this should do it! Right?
...no? It doesn't work, because the syntax for performing ERB is expecting quotation marks around that. So we'll go do that:
And this will make:
...what on earth? Oh, because it expects an array, right? So adding a bracket surrounding the variable should close it up nicely:
This should do it:
Not exactly what we expected. We got the names of the ethercrafts all there/ But they're covered in " before and after!
What exactly happened here? The long and the short of it is that during the processing via Ruby/ActiveRecord -> ERB -> Javascript -> HTML, the array of our ethercrafts were in this form:
However, through all that, the quotation marks were read and parsed into the " text. So how do we fix this? Let's take a look at the source code while we're at it (very important thing to do as well, it's a good habit I've picked up.).
Our window.ETHERCRAFT has our ethercraft array within the array we added earlier. That's strange! However, this does explain some things. When JavaScript expects an array of strings, like when we are trying to define the X-Axis Categories for Highcharts expects quoted strings separated by commas. Now, the quotes don't exist when Javascript reads it, so we end up with the " mess or a plain syntax error prior to adding our overarching quotes or array boxes. But now, we end up with this.
So how do we fix it? A handy function to use is to use the raw form of our HTML to be read into the Javascript, which we'll add to our ERB file as we render our ethercrafts variable:
We remove the quotations and the array, as our instance variable already contains our square array and our strings separated by quotes and covered with individual quotation marks for each through our method in the controller. This is exactly the format Javascript will expect, so this is what we get:
Hooray! We've done it.
And so ends this post where I describe my morning. I get closer to making highcharts usable for census data, and learn how to move raw data from Rails to ERB to JS to HTML. A very nifty lesson, overall.
Hope this helps. Comments, criticisms and advice are wholly welcome!
But to actually get there, I need some data beyond static example data of John and Jane eating fruits. So, I worked on passing PSQL database objects into the AJAX file in Rails, so that I could apply the variables I want into the chart. How and why would someone do this? It's fairly obvious why, but an example would illustrate things a bit better.
The chart is merely an example; there's many situations where one would want to transfer a database item, or value, or anything into their AJAX file, but that's moving things from Ruby to ERB to JS to HTML. The core issue to keep in mind is to keep the object being passed around readable all the way.
In this case, we'll make a chart that depicts a census of people with different jobs in different countries. In this fantasy fiction world, we'll call them ethercrafts to describe how they cast their magic spells in their day to day. There are 2 countries in this example, Zahnheim and Rogalia. The end result is to look like this:
There's 5 different ethercrafts in the chart: Soulreaving, Enforcing, Invoking, Evoking and Empty. The bar graph (admittedly, not the best chart type to describe population, but it'll suit this blogpost) will compare the two countries' populations for each type of ethercraft.
For this post, we'll focus on the X-Axis descriptors, the ethercrafts. Currently, it describes those by the following code in the Highcharts javascript in the ajax file:
The first variable, ethercrafts is a list of the ethercrafts as strings in an array which will be the xAxis categories, (we'll talk about this further down). Next is an array to describe the countries that will be the series in the graph. Each country is listed, along with the population of people with a certain ethercraft described in magic constant numbers. We don't want magic numbers, but for the time being, those will work for this example - country population variables will come next time as I make progress on highcharts.
Next variable is the options that we'll pass into the chart we want to make. Highcharts lets you name this anything you want, as this variable will just contain a lot of data which will be passed in as an argument for the Chart function which expects its options. The options include where it's being rendered to (in this case, an HTML object with the ID 'container') and the type of chart, which is bar, the title of the chart, what the categories in the xAxis is (which is our ethercrafts variable, where it expects an array), and the yAxis, where we describe the numbers as population in thousands. Lastly, we describe the series - which expects an array, along with the relevant data. It passes in the countries variable from before.
Lastly, we have the last variable which is a function to create a new highcharts chart with our options passed in as the first argument.
We'll focus on the ethercraft variable here. Right now, this is what we have for ethercrafts in the AJAX file:
But these are all constants. What if (and we have) an Ethercraft class in our ActiveRecord, which also describes these 5 currently and would like to use that? Imagine if there's more than just 5 ethercrafts, like how there's more than 5 different genres of music and we wanted the graph to reflect that?
We'll first need to get all the ethercrafts in ActiveRecord first, and present it as an array of the names of Ethercrafts. Otherwise, we'll just have an ActiveRecord Relation object that describes all the items or the Object References to the Ethercraft items, or worse.
Firstly, in the controller where the graph will be displayed, we can use the following private method and store it in a single instance variable, such as @ethercrafts:
With that done, next we'll need to change the variable in our AJAX file to take in the collection of the different types of Ethercrafts from ActiveRecord (via our instance variable, @ethercrafts). To do that, we can go to our application.html.erb, and add in our header:
Then we should change the ethercrafts reference in the AJAX file and point it to window.ETHERCRAFT. And this should do it! Right?
...no? It doesn't work, because the syntax for performing ERB is expecting quotation marks around that. So we'll go do that:
And this will make:
This should do it:
Not exactly what we expected. We got the names of the ethercrafts all there/ But they're covered in " before and after!
What exactly happened here? The long and the short of it is that during the processing via Ruby/ActiveRecord -> ERB -> Javascript -> HTML, the array of our ethercrafts were in this form:
["Soulreaving", "Enforcement", "Invoking", "Evoking", "Empty"]
However, through all that, the quotation marks were read and parsed into the " text. So how do we fix this? Let's take a look at the source code while we're at it (very important thing to do as well, it's a good habit I've picked up.).
Our window.ETHERCRAFT has our ethercraft array within the array we added earlier. That's strange! However, this does explain some things. When JavaScript expects an array of strings, like when we are trying to define the X-Axis Categories for Highcharts expects quoted strings separated by commas. Now, the quotes don't exist when Javascript reads it, so we end up with the " mess or a plain syntax error prior to adding our overarching quotes or array boxes. But now, we end up with this.
So how do we fix it? A handy function to use is to use the raw form of our HTML to be read into the Javascript, which we'll add to our ERB file as we render our ethercrafts variable:
Hooray! We've done it.
And so ends this post where I describe my morning. I get closer to making highcharts usable for census data, and learn how to move raw data from Rails to ERB to JS to HTML. A very nifty lesson, overall.
Hope this helps. Comments, criticisms and advice are wholly welcome!
Thursday 25 September 2014
Starting Highcharts
I was looking into highcharts due to the popularity of presenting data on websites and apps nowadays. Highcharts is part of a series of JavaScript based apps that features interactive display along with HighStock and HighMaps - and they look pretty sleek.
As you highlight your mouse over the bars, a small box describes exactly what you want. And the implementation thus far seems to be so simple. I'll be working on this over the next few days to see how I can put in variables as data - the site has a way for people to get started.
But, keep in mind that on Ruby on Rails we like to compartmentalize our scripts and sources. Normally, you'd put in your head tags (as instructed in the Highcharts tutorial:)
But there is now a gem for highcharts, highcharts-rails. So all we'd need is to add this gem to our gemfile and we can just plug in highchart scripts and methods into our Ajax file:
And then we're all set. This above example was as easy as making a new div with the id 'container' anywhere on my HTML, and using the following, copy pasted code from the highcharts example into your JQuery code:
From the look of things, we could probably put in variables in the array. This is looking like straightforward JQuery. I will definitely be meddling around here to get what I want for statistics. It definitely seems like a versatile and very powerful chart API.
But, keep in mind that on Ruby on Rails we like to compartmentalize our scripts and sources. Normally, you'd put in your head tags (as instructed in the Highcharts tutorial:)
<'script' src="http://ajax.googleapis.com/ajax/libs/jquery/1.8.2/jquery.min.js"></'script'>
<'script' src="http://code.highcharts.com/highcharts.js">
</'script'> But there is now a gem for highcharts, highcharts-rails. So all we'd need is to add this gem to our gemfile and we can just plug in highchart scripts and methods into our Ajax file:
In Gemfile:
gem "highcharts-rails", "~> 3.0.0"
In app/assets/javascripts/application.js, add to the end:
//= require highcharts
//= require highcharts/highcharts-more
And then we're all set. This above example was as easy as making a new div with the id 'container' anywhere on my HTML, and using the following, copy pasted code from the highcharts example into your JQuery code:
From the look of things, we could probably put in variables in the array. This is looking like straightforward JQuery. I will definitely be meddling around here to get what I want for statistics. It definitely seems like a versatile and very powerful chart API.
Wednesday 24 September 2014
The little things between form and 'form'
After a long trip following my graduation from Metis, I went back proper into a routine this week. And today, I learned a great tidbit about how to render forms in Rails, very simple but it saves me a lot of time from now on.
I used to write the following:
For rendering a form partial. I couldn't just not put in the 'form: form' part because it would always say that form doesn't exist in the partial (in the form partial, there was - obviously, a form with it's associated fields designated as form such as form.text_area, and so on).
However, one of my colleagues pointed this out to me that I could just do:
The difference? By removing the quotations, Rails magic will immediately do the previous line I put up for me. That is very convenient, and actually solves a lot of my hassles (I've always wondered how people just write render form - and now I realize it's just the quotes!).
I used to write the following:
<%= render 'form', form: form %>
For rendering a form partial. I couldn't just not put in the 'form: form' part because it would always say that form doesn't exist in the partial (in the form partial, there was - obviously, a form with it's associated fields designated as form such as form.text_area, and so on).
However, one of my colleagues pointed this out to me that I could just do:
<%= render form %>
The difference? By removing the quotations, Rails magic will immediately do the previous line I put up for me. That is very convenient, and actually solves a lot of my hassles (I've always wondered how people just write render form - and now I realize it's just the quotes!).
Sunday 31 August 2014
HabitRPG
So I was wandering around Hacker News today, and I came across something exactly what I was hoping to do last year!
Enter HabitRPG, a to-do list with a gamified twist. It has dailies, to-dos, habits (good and bad) and the ability to reward yourself. Basically, you have an avatar, with stats and experience points - things you'd expect in an RPG - and as you do tasks, dailies or good habits, you gain exp and money. With money, you can buy new costumes or pets for your avatar - very addictive things that are used to be so common all over the internet (NeoPets, that dragon egg signature thing on forums?). It's genius, because people who are attracted to such a feature will find themselves much more motivated.
So how does one motivate oneself to do it further? Social networking, of course. It integrates with Facebook - which is something I have to check to be sure, but if it does what I think it does with Facebook, you'll be able to see each other's progress and that usual peer pressure does the rest. It's kind of like how you brag to others about what you're doing - you're much more likely to follow through after!
You can also form parties, too, and take on various quests/challenges. In parties, you can see each other's progress (another form of peer pressure), and challenges involve giving yourself new tasks between you and your party that you share and do.
It's great! I'm definitely going to use this between bouts of Trello (They have a Trello board too for things they need doing, to boot.)
On another note, they need people to contribute! People to spread word of mouth, people to write, people to art, and people to code! For code, they use Angular JS for both web and mobile (apparently, it makes it very easy to transfer between web and mobile codes.). They use Mongoose for the database and ExpressJS for their API server. Some things to look into, I'm sure if I want to contribute. It's a worthwhile effort, I think, and Angular is pretty big lately.
In the meantime, though, I'm going to go gain a few levels as I complete tasks. :D
Enter HabitRPG, a to-do list with a gamified twist. It has dailies, to-dos, habits (good and bad) and the ability to reward yourself. Basically, you have an avatar, with stats and experience points - things you'd expect in an RPG - and as you do tasks, dailies or good habits, you gain exp and money. With money, you can buy new costumes or pets for your avatar - very addictive things that are used to be so common all over the internet (NeoPets, that dragon egg signature thing on forums?). It's genius, because people who are attracted to such a feature will find themselves much more motivated.
So how does one motivate oneself to do it further? Social networking, of course. It integrates with Facebook - which is something I have to check to be sure, but if it does what I think it does with Facebook, you'll be able to see each other's progress and that usual peer pressure does the rest. It's kind of like how you brag to others about what you're doing - you're much more likely to follow through after!
You can also form parties, too, and take on various quests/challenges. In parties, you can see each other's progress (another form of peer pressure), and challenges involve giving yourself new tasks between you and your party that you share and do.
It's great! I'm definitely going to use this between bouts of Trello (They have a Trello board too for things they need doing, to boot.)
On another note, they need people to contribute! People to spread word of mouth, people to write, people to art, and people to code! For code, they use Angular JS for both web and mobile (apparently, it makes it very easy to transfer between web and mobile codes.). They use Mongoose for the database and ExpressJS for their API server. Some things to look into, I'm sure if I want to contribute. It's a worthwhile effort, I think, and Angular is pretty big lately.
In the meantime, though, I'm going to go gain a few levels as I complete tasks. :D
Friday 29 August 2014
Start of something new
With Wednesday, Metis' career day behind us, we're finished with the course - but there's tons of resources we still have access to. However, we're now fully-fledged junior developers at this point.
It's been an incredible ride; and while I've said that several times throughout the blog, it still hasn't changed one bit. I've learned a lot, and we've been taught much. At the start, I only had what I gathered from my experiences in RMXP and video game modding, and now I can make full fledged web apps, the design principles to make them be powerful, flexible and lean, the various languages and tools to build them on and the drive and resources to move on.
It's wonderous what 3 months can achieve, and I really have gotten used to the idea of how what I have now is able to create things to help people with. I can express my creativity and my desire to help others or myself through what I've learned.
Creative writing is one of my favourite pastimes, and in that regard, I've found that coding isn't too different from it. In a sense, we are creating things - we are building something as a sort of creative need within us as builders. There's many ways to tell a story, or to paint a picture, or to write code that all convey or do the same thing. The processes that we go through and the challenges we face are all very similar to one another. We have to figure out how to overcome the hurdles of burn out, how to motivate ourselves, or those moments where we feel like we can't come up with anything valuable or something people would want, or times where we think we're weaker than our peers.
In that regard, coding requires the same dedication or passion as writing. I think that's why I've fallen in love with this particular art. While creative writing will be a pastime for me, I feel that it serves me best as my tool of self expression and introspection. Code, on the other hand, is my way to really create things for others. I have a lot of projects lined up that I think of daily as I ponder about family, friends and colleagues that could use my talents to make a few of their problems easier.
Definitely, now that I walk out of thoughtbot's office as a Metis graduate, I feel like I can code a lot more challenging apps, and these challenges are things I'd be glad to tackle.
It's been an incredible ride; and while I've said that several times throughout the blog, it still hasn't changed one bit. I've learned a lot, and we've been taught much. At the start, I only had what I gathered from my experiences in RMXP and video game modding, and now I can make full fledged web apps, the design principles to make them be powerful, flexible and lean, the various languages and tools to build them on and the drive and resources to move on.
It's wonderous what 3 months can achieve, and I really have gotten used to the idea of how what I have now is able to create things to help people with. I can express my creativity and my desire to help others or myself through what I've learned.
Creative writing is one of my favourite pastimes, and in that regard, I've found that coding isn't too different from it. In a sense, we are creating things - we are building something as a sort of creative need within us as builders. There's many ways to tell a story, or to paint a picture, or to write code that all convey or do the same thing. The processes that we go through and the challenges we face are all very similar to one another. We have to figure out how to overcome the hurdles of burn out, how to motivate ourselves, or those moments where we feel like we can't come up with anything valuable or something people would want, or times where we think we're weaker than our peers.
In that regard, coding requires the same dedication or passion as writing. I think that's why I've fallen in love with this particular art. While creative writing will be a pastime for me, I feel that it serves me best as my tool of self expression and introspection. Code, on the other hand, is my way to really create things for others. I have a lot of projects lined up that I think of daily as I ponder about family, friends and colleagues that could use my talents to make a few of their problems easier.
Definitely, now that I walk out of thoughtbot's office as a Metis graduate, I feel like I can code a lot more challenging apps, and these challenges are things I'd be glad to tackle.
Friday 15 August 2014
Using Carrierwave and Fog
Following up installing RMagick in my previous post, I added Carrierwave and Fog. For the most part, instructions on getting Carrierwave running with Fog are in line with what I gathered in this blog post by JavaHabit. However, there's a few things to keep in mind:
Basically:
Add the dotenv-rails gem in your gemfile:
In your fog.rb file, trim it down as much as possible and make the key hashes point to an ENV.fetch of the keys you need:
In your .env file, make the following definitions for env variables:
In your gitignore file, add the uploads folder and .env to avoid uploading your images (if any) and secret keys onto github:
Lastly, in ImageUploader:
And that should set Fog up for your Carrierwave. Hope it helps!
- Once you get your fog.rb generated, be sure to move it to your config/initializers folder.
- If you plan on pushing your app to heroku, don't link your secret keys within the fog.rb file, you should install the dotenv-rails gem, make a .env file, put the keys inside it, then be sure to use ENV.fetch in the fog.rb file to obtain the keys remotely. Add .env to the gitignore file.
- Restart your server. Additionally, it's best to convert the hash syntax within the fog.rb file to the newer rails style (if you use version 4).
- Common error fixes: restart the server, remove the region line, and keep the fog.rb file to the bare minimum (delete mostlines to make most things set to their defaults). Those are the most common SO answers I've found.
Basically:
Add the dotenv-rails gem in your gemfile:
gem 'dotenv-rails' In your fog.rb file, trim it down as much as possible and make the key hashes point to an ENV.fetch of the keys you need:
CarrierWave.configure do |config| config.fog_credentials = { provider: 'AWS', aws_access_key_id: ENV.fetch("AWS_ACCESS_KEY_ID"), aws_secret_access_key: ENV.fetch("AWS_SECRET_ACCESS_KEY"), } config.fog_directory = "bucketname" config.fog_attributes = {"Cache-Control'=>'max-age=315576000"}endIn your .env file, make the following definitions for env variables:
AWS_ACCESS_KEY_ID=accesskey AWS_SECRET_ACCESS_KEY=secretaccesskeyIn your gitignore file, add the uploads folder and .env to avoid uploading your images (if any) and secret keys onto github:
/public/uploads.env
Lastly, in ImageUploader:
storage :fogAnd that should set Fog up for your Carrierwave. Hope it helps!
Wednesday 13 August 2014
Installing RMagick on Windows
Today while working on our project, I was facing trouble installing RMagick. It was - as expected, a windows issue, and while most guides on troubleshooting were old and out of date, a more recent Stack Overflow response (January 2014) more or less pointed out the issue was that Windows might not be supported in the more recent versions of ImageMagick with RMagick. So the solution was to use older versions when it worked, and it definitely solved my issue in installing it.
To sum up and quote the answer by Dany Khalife:
And that's all there is to it. 'bundle install' should work just as well, too for the rails project. Hope this helps!
To sum up and quote the answer by Dany Khalife:
Uninstall ImageMagick and re-install a previous version that works with your Ruby setup.Keep in mind the version numbers! I'm running on Ruby 2.0.0 and it worked just fine. Be sure to use the following command, assuming ImageMagick was installed in C:/ :
This is what worked for me :
- Ruby 1.9.3
- Dev Kit 32-4.5.2
- ImageMagick 6.7.7 (i had a really hard time finding binary versions for legacy versions of ImageMagick so i guess this link will be handy for you: http://ftp.sunet.se/pub/multimedia/graphics/ImageMagick/binaries/)
- Rmagick 2.13.2
gem install rmagick --version=2.13.2 --platform=ruby -- --with-opt-lib=c:/ImageMagick/lib --with-opt-include=c:/ImageMagick/include And that's all there is to it. 'bundle install' should work just as well, too for the rails project. Hope this helps!
Thursday 17 July 2014
Writing Clean Code
Been awhile since my last post!
The last weeks have been refining our skill at using Ruby On Rails and going back to the basics. Most of this week has been about refining our codes and writing them cleanly, to make sure we have good conventions in terms of our writing code, and being able to go back and refactoring them.
This week we had 3 apps to practice writing clean code on. We had several sources to guide us this week.
First we had a video conference shown to us by Sandi Metz. She spoke about the design principles of SOLID object oriented code design; Very helpful to get a good foundation on how to start writing code. It aims to act as a guideline where to start writing the code and a set of principles to keep in mind.
On the second day we had a video from Aloha Ruby Con 2012 featuring Thoughtbot's Ben Orenstein speaking on refactoring from good to great. His talk highlights the importance of shifting methods to classes and minimizing the size of methods as much as possible. It's important to consider when your code can be shortened or refactored after you first make it. Methods should be written clearly and be as succinct as possible, and where variables are often repeated or passed around constantly it is usually best to shift the methods or variables to classes. That way, there are shorter classes, shorter methods and they are targeted and compartmentalized. This is an important concept to grasp to write clean code.
On Wednesday, we saw a talk by Avdi Grimm in Ruby Midwest 2011, speaking of confident code. The important message of the talk was that when writing code, we should 'tell, don't ask'. Code we right should have as little case statements and queries onto the properties of variables as much as possible, or else we run into the issue of 'timid code'. We need to adhere to duck typing - where we treat objects as what they are without having to ask what they are. This is exceptionally important with NilClasses, which is probably the most common cause for a query onto the class for the variable. In short, we should avoid 'if class == nil' statements, and simply handle NilClasses as if we expected them to come, or any other class that might come down our program. It's an important philosophy to grasp, where we own and understand our code. In the case of timid code, we would ask or approach the code carefully, which implies we don't understand or own the code we've written. or are reading.
Avdi's particular talk was very fascinating, and it was incredibly helpful in overcoming a programming challenge we had that day to query for hotels from a database, which I'll describe here. This particular blog post by Avdi describes the Null Object and their level of falsiness.
Between all these talks, we had a good grounding to stand on to start work on several programming challenges aimed at improving how we write code cleanly and how to refactor them after the fact, along with the process of handling pull requests.
For our programming challenge, we have to load up a CSV file that contains a table of various hotels/properties (I refer to them as properties, in case the list contains hotels, motels, inns, etc.), and the app will inquire the user for the name of a hotel they're looking for. It will print to the user details on the hotel if it is found, and when there is no property with a name they've written, it will tell the user no such property exists.
We have the main class, PropertyQuery which is what the user will be interacting most frequently. It takes in a properties variable on initialize, which should contain the table that should be read up by another class that returns the data. It is stored in the instance variable @properties . Afterwards, the instance of the class calls for the basic query process to be called in the method ask_user_for_query .
First, we'll look at how the class PropertyReader takes in and processes the table file. After the data is processed, it'll take the data and pass it to PropertyQuery.new as This is the .csv file:
Very simply, it has the hotel name, the city it's located in, the phone number, and the number of single or double rooms. This information needs to be passed into the PropertyReader class instance:
In this class, it takes in the file when an instance of PropertyReader is created and passes it to instance variable @file. It fills in @properties with new Property instances (see below) using the foreach method called with headers set to true as an option to take in the .csv file by row with the first row being for headers.
Each row is taken in as a hash with the headers being the keys, and the items in the rows being the values. Each row is a new instance of Property containing this key-value pair. While it is entirely possible to write up code to avoid using a new class altogether and creating individual hashes to fill @properties with instead, it's highly inefficient. We'd have to make explicit references to a specific hash shoveled into the @properties array or even worse call .each on it (which is very ineffective if the hash has a lot of records). Not to mention, we'd have to pull out the keys to obtain the values of particular item in the array we're looking for, and it makes it very difficult to read and conceptualize, and clogs up the code or class with so many additional methods and lines.
One of the things we learned during the 3 talks is that coders are often very timid or afraid to push their methods and code onto new classes. New classes actually make it very easy and saves up space (a huge plus) and improves readability, and enforces the tell, don't ask policy. We'll be able to take better grasp of our code by being able to define our own methods and properties onto our instances of classes. The thing about instance of classes is, they are very malleable. By shifting our thought process from simply compartmentalizing our code into single, large classes and onto classes as a collective, we're capable of confidently wielding the code we write as we see fit.
So to recap: we've made new instances of Property, which don't even need a variable name associated with them (a unique identifier based on object ID is created for every new instance). And these instances contain a hash of information (keys being the headers on the CSV file, values being the respective values associated to a single property like the name, city, etc.). These are all shoveled into an instance variable @properties within an instance of PropertyReader. Now, what can we do with these instances of Property? We want to be able to access their information, and by nature we can't access methods normally available to hashes when we have the instances outside the class (due to the hashes being in instances of Property). So how would we access them in another class' method? First, we define getter methods within Property, like so:
By having these methods on hand, we can call name on instances of Property to obtain the value of "Hotel", which is the name of the hotel. Or phone for the phone number of that Property instance. But recall that we are shoveling these instances into an instance variable within PropertyReader...
Which means that we'll need to be able to pass that array of instances containing a hash onto our main PropertyQuery class. For that reason, we call attr_reader on it to have a getter method we can use in our PropertyQuery:
Look at line 29-32 in particular. We load up a new instance of PropertyReader that takes in our .csv file, then it uses the command read_file on the instance to obtain and shovel the data into @properties within it; and then when we load up a new instance of PropertyQuery, we pass in property_reader.properties (a getter method we obtain when we used attr_reader on @properties). This gives us access to the array of instances of Property for use as our argument in PropertyQuery. Finally, on initialize, this gets passed into our instance variable @properties. Ultimately, this gets used in the method on line 24.
When this program is run and the data is loaded up into a PropertyQuery instance, the users are asked to put in the hotel name. Their query is passed into find_result, and their query is checked if it exists within our array of Property instances using .detect. With .detect, each item in the array is checked for a true condition and returns what was found. And here, with our instances we can use our defined .name method to obtain the value of the Hotel key in our instance. The first match is passed off as true and that will tell us we've found our hotel, returning that instance of Property. Earlier in the method definitions for PropertyQuery, the next step after query_for_property was to run .display, which is also a method for instances of Property to show all details for the property found.
However, note the || OR condition in the detect. Assuming there's no matches, then .detect will naturally return nil. But in this case, NullProperty.new is run in case the first half of the .detect command returns false, instead of just returning nil.
A timid programmer, as Avdi might define it would put an if statement to check if the return was nil. That's 3 lines at the minimum to check if @properties.detect returned Nil or NilClass! So what does NullProperty.new do in this case?
In short, this NullProperty class contains a method, display. Keep in mind that with instances of Property, we have a method for display too - but that does something vastly different. And PropertyQuery was written with the intention of doing .display following the find_result method was run - so no matter the result of @properties.detect, we'll always run .display on whatever we get - and instance of Property, or an instance of NullProperty.
This way, instead of going to ask and thus coming up with a case condition when we run into Nil in our query, we've managed to take control of Nil when it comes up (inevitably) in the user query. For that reason, the method find_result in PropertyQuery can only have one line.
By being able to use Class instances in this way we can be far more flexible and save a lot of lines. Our methods become far shorter and smaller, it becomes better to read (compared to the alternative we might've had to face), and it becomes less dependant on each other. By being less dependant, we're able to refactor this code if necessary without breaking another part of the code. This follows a fair bit of the Tell, don't ask philosophy and shows duck-typing - treating classes for what they are and not asking if they are of a particular class.
Next up in the exercise is to be able to use fuzzy searching with Regexp so we're able to find or suggest hotels that make partial matches in the name - in fact, remember the Zombies challenge I wrote about almost two months ago? The code is probably a bit of a mess, and it could definitely use a cleaner, effective rewrite - and now that I know about Regexp for fuzzy searching, I might even be able to cut down the code substantially to find matches or duplicate terms in the zombie dictionary...
I'm constantly reminded google searching, docs and other people are incredible help to find information and new tips. Videos, books and blogs are huge resources, and I really have grown to appreciate them.
So hopefully, this blog post comes up and helps you out somewhere down the line! Thanks for reading. :) Feel free to comment and let me know if there's a gap or something I misunderstood, too! I appreciate it.
Link to Git Repo: Here
The last weeks have been refining our skill at using Ruby On Rails and going back to the basics. Most of this week has been about refining our codes and writing them cleanly, to make sure we have good conventions in terms of our writing code, and being able to go back and refactoring them.
This week we had 3 apps to practice writing clean code on. We had several sources to guide us this week.
First we had a video conference shown to us by Sandi Metz. She spoke about the design principles of SOLID object oriented code design; Very helpful to get a good foundation on how to start writing code. It aims to act as a guideline where to start writing the code and a set of principles to keep in mind.
- Single Responsibility - no more than 1 reason for classes to change and the class should have only one responsibility
- Open/Close - modules should be open for extension but closed for modification
- Liskov Substitution - Objects should be substitutable by instances of its subclasses without affecting the program
- Interface Segregation - Don't make a class depend on methods its objects might not use, and specific interfaces are better than a single general purpose interface
- Dependency Inversion - Depend on abstractions, not concretions.High level modules shouldn't depend on low-level modules, and both should depend on abstractions.
On the second day we had a video from Aloha Ruby Con 2012 featuring Thoughtbot's Ben Orenstein speaking on refactoring from good to great. His talk highlights the importance of shifting methods to classes and minimizing the size of methods as much as possible. It's important to consider when your code can be shortened or refactored after you first make it. Methods should be written clearly and be as succinct as possible, and where variables are often repeated or passed around constantly it is usually best to shift the methods or variables to classes. That way, there are shorter classes, shorter methods and they are targeted and compartmentalized. This is an important concept to grasp to write clean code.
On Wednesday, we saw a talk by Avdi Grimm in Ruby Midwest 2011, speaking of confident code. The important message of the talk was that when writing code, we should 'tell, don't ask'. Code we right should have as little case statements and queries onto the properties of variables as much as possible, or else we run into the issue of 'timid code'. We need to adhere to duck typing - where we treat objects as what they are without having to ask what they are. This is exceptionally important with NilClasses, which is probably the most common cause for a query onto the class for the variable. In short, we should avoid 'if class == nil' statements, and simply handle NilClasses as if we expected them to come, or any other class that might come down our program. It's an important philosophy to grasp, where we own and understand our code. In the case of timid code, we would ask or approach the code carefully, which implies we don't understand or own the code we've written. or are reading.
Avdi's particular talk was very fascinating, and it was incredibly helpful in overcoming a programming challenge we had that day to query for hotels from a database, which I'll describe here. This particular blog post by Avdi describes the Null Object and their level of falsiness.
Between all these talks, we had a good grounding to stand on to start work on several programming challenges aimed at improving how we write code cleanly and how to refactor them after the fact, along with the process of handling pull requests.
For our programming challenge, we have to load up a CSV file that contains a table of various hotels/properties (I refer to them as properties, in case the list contains hotels, motels, inns, etc.), and the app will inquire the user for the name of a hotel they're looking for. It will print to the user details on the hotel if it is found, and when there is no property with a name they've written, it will tell the user no such property exists.
First, we'll look at how the class PropertyReader takes in and processes the table file. After the data is processed, it'll take the data and pass it to PropertyQuery.new as This is the .csv file:
Very simply, it has the hotel name, the city it's located in, the phone number, and the number of single or double rooms. This information needs to be passed into the PropertyReader class instance:
Each row is taken in as a hash with the headers being the keys, and the items in the rows being the values. Each row is a new instance of Property containing this key-value pair. While it is entirely possible to write up code to avoid using a new class altogether and creating individual hashes to fill @properties with instead, it's highly inefficient. We'd have to make explicit references to a specific hash shoveled into the @properties array or even worse call .each on it (which is very ineffective if the hash has a lot of records). Not to mention, we'd have to pull out the keys to obtain the values of particular item in the array we're looking for, and it makes it very difficult to read and conceptualize, and clogs up the code or class with so many additional methods and lines.
One of the things we learned during the 3 talks is that coders are often very timid or afraid to push their methods and code onto new classes. New classes actually make it very easy and saves up space (a huge plus) and improves readability, and enforces the tell, don't ask policy. We'll be able to take better grasp of our code by being able to define our own methods and properties onto our instances of classes. The thing about instance of classes is, they are very malleable. By shifting our thought process from simply compartmentalizing our code into single, large classes and onto classes as a collective, we're capable of confidently wielding the code we write as we see fit.
So to recap: we've made new instances of Property, which don't even need a variable name associated with them (a unique identifier based on object ID is created for every new instance). And these instances contain a hash of information (keys being the headers on the CSV file, values being the respective values associated to a single property like the name, city, etc.). These are all shoveled into an instance variable @properties within an instance of PropertyReader. Now, what can we do with these instances of Property? We want to be able to access their information, and by nature we can't access methods normally available to hashes when we have the instances outside the class (due to the hashes being in instances of Property). So how would we access them in another class' method? First, we define getter methods within Property, like so:
By having these methods on hand, we can call name on instances of Property to obtain the value of "Hotel", which is the name of the hotel. Or phone for the phone number of that Property instance. But recall that we are shoveling these instances into an instance variable within PropertyReader...
Which means that we'll need to be able to pass that array of instances containing a hash onto our main PropertyQuery class. For that reason, we call attr_reader on it to have a getter method we can use in our PropertyQuery:
When this program is run and the data is loaded up into a PropertyQuery instance, the users are asked to put in the hotel name. Their query is passed into find_result, and their query is checked if it exists within our array of Property instances using .detect. With .detect, each item in the array is checked for a true condition and returns what was found. And here, with our instances we can use our defined .name method to obtain the value of the Hotel key in our instance. The first match is passed off as true and that will tell us we've found our hotel, returning that instance of Property. Earlier in the method definitions for PropertyQuery, the next step after query_for_property was to run .display, which is also a method for instances of Property to show all details for the property found.
However, note the || OR condition in the detect. Assuming there's no matches, then .detect will naturally return nil. But in this case, NullProperty.new is run in case the first half of the .detect command returns false, instead of just returning nil.
A timid programmer, as Avdi might define it would put an if statement to check if the return was nil. That's 3 lines at the minimum to check if @properties.detect returned Nil or NilClass! So what does NullProperty.new do in this case?
In short, this NullProperty class contains a method, display. Keep in mind that with instances of Property, we have a method for display too - but that does something vastly different. And PropertyQuery was written with the intention of doing .display following the find_result method was run - so no matter the result of @properties.detect, we'll always run .display on whatever we get - and instance of Property, or an instance of NullProperty.
This way, instead of going to ask and thus coming up with a case condition when we run into Nil in our query, we've managed to take control of Nil when it comes up (inevitably) in the user query. For that reason, the method find_result in PropertyQuery can only have one line.
By being able to use Class instances in this way we can be far more flexible and save a lot of lines. Our methods become far shorter and smaller, it becomes better to read (compared to the alternative we might've had to face), and it becomes less dependant on each other. By being less dependant, we're able to refactor this code if necessary without breaking another part of the code. This follows a fair bit of the Tell, don't ask philosophy and shows duck-typing - treating classes for what they are and not asking if they are of a particular class.
Next up in the exercise is to be able to use fuzzy searching with Regexp so we're able to find or suggest hotels that make partial matches in the name - in fact, remember the Zombies challenge I wrote about almost two months ago? The code is probably a bit of a mess, and it could definitely use a cleaner, effective rewrite - and now that I know about Regexp for fuzzy searching, I might even be able to cut down the code substantially to find matches or duplicate terms in the zombie dictionary...
I'm constantly reminded google searching, docs and other people are incredible help to find information and new tips. Videos, books and blogs are huge resources, and I really have grown to appreciate them.
So hopefully, this blog post comes up and helps you out somewhere down the line! Thanks for reading. :) Feel free to comment and let me know if there's a gap or something I misunderstood, too! I appreciate it.
Link to Git Repo: Here
Monday 7 July 2014
Foraying into JavaScript
Today begins the day where we learn JavaScript. My experiences with JavaScript are numerous, though how fruitful it is varies. At times, they go great. Othertimes, they don't. My biggest JavaScript run-ins are a somewhat-unfinished mod for Skyrim using the CreationKit's JavaScript-based papyrus, or when I tried to make Android apps. JavaScript is fairly difficult and compared to Ruby, a lot less 'face-value readable'.
So our first exercise in learning how to apply JavaScript to webpages is to make a very simple calculator and guessing game. Straightforward, very simple. And below are the notes I took as we were going through it as a class.
JavaScript gives us the power to make dynamic things happen on the client side. Where Rails and the Rails stack processes and renders views server-side, but java-script tells the user to render on the client. Browsers all accept JavaScript. ECMAScripts organize JavaScript and standardize it. It allows the user to interact with the Document Object Model, or the DOM. We can send smaller requests to the server via JavaScript instead of large chunks of whole views so it becomes more dynamic.
By default, a submitted form in HTML with no direction will send a get request to itself with the params. It won't actually send anything; but the params itself need to be obtained through the URL - which is the name field in the input tags:
<input type="number" name="left">
This will make a query-param get request with left having a value of what we had put in, with all params separated by ampersands:
/calculator.html?left=5&operator=*&right=3
--
HTML has a callback for forms, called onsubmit, which allows us to call javascript function. JavaScript functions can be passed around and will not run until called. Callbacks listen for events and will do an action when it happens. To prevent the forms from doing it's defalt behaviour for submit (as described abve - get request to itself), we can use return false in the onsubmit form.
To begin writing javascript in the html file, we can use <script> tags in the header.
To define a function in JavaScript, we define it with function:
function calculate() {
}
Where parameters are required, all functions must contain a param bracket (). All variables in the function need to be defined by 'var' then the name of the variable, and then to obtain params from the elements on the website we can call getElement on document. Specifically, we can getElementById (for example, our input type friend called left), thus:
var left = document.getElementById("left").value
But we have to make sure that we defined "left" as an ID in the form itself:
<input type="number" name="left" id="left">
In addition to being able to define and store param variables, we can also log them:
console.log(left)
When we do:
if (operator == "+") {
console.log(left + right);
}
We'll be adding the var left with var right. However, they might come out as strings:
log:
3 + 2
32
Which doesn't work for us. We have to typecast them (basically, turn them into integers in this case). Type casting in JScript basically parses in a parameter to a constructor and makes a number object:
var left = Number(document.getElementById("left").value;
And now we re-run the submit:
log:
3 + 2
5
If we wanted to do live debugging, we can put in a debugger statement:
<script>
function calculate(){
var left = Number(document.getElementById("left").value);
var right = Number(document.getElementById("right").value);
var operator = document.getElementById("operator").value;
debugger;
}
</script>
It will pause the script as it is running upon reaching the debugger. It allows us to debug whenever it makes a request for a parameter or call anything in that context. Very useful.
Javascript will allow us to append or add dynamically to the view. So if we want to display the results of our calculation. To where we want our calculation result:
<p>Result: <span id="result"></p>
We also have to make sure that we specify the variable and get the element by its ID:
var result = document.GetElementById("result");
And then we also have to allow the variable to change the value of a particular element in our calculation itself by calling innerHTML on the variable:
if (operator == "+") {
result.innerHTML = left + right
}
And that should do it!
Complete gist here .
So our first exercise in learning how to apply JavaScript to webpages is to make a very simple calculator and guessing game. Straightforward, very simple. And below are the notes I took as we were going through it as a class.
JavaScript gives us the power to make dynamic things happen on the client side. Where Rails and the Rails stack processes and renders views server-side, but java-script tells the user to render on the client. Browsers all accept JavaScript. ECMAScripts organize JavaScript and standardize it. It allows the user to interact with the Document Object Model, or the DOM. We can send smaller requests to the server via JavaScript instead of large chunks of whole views so it becomes more dynamic.
By default, a submitted form in HTML with no direction will send a get request to itself with the params. It won't actually send anything; but the params itself need to be obtained through the URL - which is the name field in the input tags:
<input type="number" name="left">
This will make a query-param get request with left having a value of what we had put in, with all params separated by ampersands:
/calculator.html?left=5&operator=*&right=3
--
HTML has a callback for forms, called onsubmit, which allows us to call javascript function. JavaScript functions can be passed around and will not run until called. Callbacks listen for events and will do an action when it happens. To prevent the forms from doing it's defalt behaviour for submit (as described abve - get request to itself), we can use return false in the onsubmit form.
To begin writing javascript in the html file, we can use <script> tags in the header.
To define a function in JavaScript, we define it with function:
function calculate() {
}
Where parameters are required, all functions must contain a param bracket (). All variables in the function need to be defined by 'var' then the name of the variable, and then to obtain params from the elements on the website we can call getElement on document. Specifically, we can getElementById (for example, our input type friend called left), thus:
var left = document.getElementById("left").value
But we have to make sure that we defined "left" as an ID in the form itself:
<input type="number" name="left" id="left">
In addition to being able to define and store param variables, we can also log them:
console.log(left)
When we do:
if (operator == "+") {
console.log(left + right);
}
We'll be adding the var left with var right. However, they might come out as strings:
log:
3 + 2
32
Which doesn't work for us. We have to typecast them (basically, turn them into integers in this case). Type casting in JScript basically parses in a parameter to a constructor and makes a number object:
var left = Number(document.getElementById("left").value;
And now we re-run the submit:
log:
3 + 2
5
If we wanted to do live debugging, we can put in a debugger statement:
<script>
function calculate(){
var left = Number(document.getElementById("left").value);
var right = Number(document.getElementById("right").value);
var operator = document.getElementById("operator").value;
debugger;
}
</script>
It will pause the script as it is running upon reaching the debugger. It allows us to debug whenever it makes a request for a parameter or call anything in that context. Very useful.
Javascript will allow us to append or add dynamically to the view. So if we want to display the results of our calculation. To where we want our calculation result:
<p>Result: <span id="result"></p>
We also have to make sure that we specify the variable and get the element by its ID:
var result = document.GetElementById("result");
And then we also have to allow the variable to change the value of a particular element in our calculation itself by calling innerHTML on the variable:
if (operator == "+") {
result.innerHTML = left + right
}
And that should do it!
Complete gist here .
Friday 27 June 2014
A month of Metis
By the end of today, it will have been 4 weeks since I started learning at Metis. There's a lot that I've learned, and it's impressive when I think of how now I have the fundamentals to already build something great.
If there's something that really draws me into programming, it's that sense of creation you have at your fingertips. You can code together magnificent pieces of software, like how an artisan handles his craft - this is the builder of the tech era.
At Metis, broadly the four weeks covered the following:
One huge draw is the fact that programming is like a game, or a puzzle. There's many ways to solve these puzzles, and you learn that some ways are faster than others, while others are more effective or clean to look at. There's a bit of joy when I go back to old code I've written, see what I've done, grin and rewrite what I could've done better now that I'm a month into the study.
I wrote some code for the zombie dictionary a few weeks back, now, and maybe when I go back to it it'll be significantly different by the end.
That said, over the weekends I'm slowly working on getting to know Vim, and while it more or less functions similarly between Unix and Windows systems, the fundamental differences between them will take me some time to adjust - for example, we utilize Homebrew, Vundle, Thoughtbot's RCM, and dotfiles to handle and manage packages, bundles and configuration settings for Vim. With the exception of Vundle which has its own set of installations for Windows, everything else is made for a UNIX system in mind. However, I'm learning of several softwares that emulate similarly. For homebrew, I've learned of chocolatey ; and quick searches for dotfile installers and bundlers for windows have turned up a few that I still need to go through.
Given this, an important thing that I learned is the core differences in how OSX handles its system-wide installations compared to Windows (which uses environmental variables to set PATHs), and the inner workings of the dotfiles we've been installing. Ultimately, it helps me understand what is being changed 'under the hood' when we brew a bundle or run RCM. (Most of the dotfiles change internal settings in Vim, Git, RailsVim and TMux among many others).
Like I said, there will be a part two for that, so that should be coming following further dives into converting from Sublime Text to Vim.
If there's something that really draws me into programming, it's that sense of creation you have at your fingertips. You can code together magnificent pieces of software, like how an artisan handles his craft - this is the builder of the tech era.
At Metis, broadly the four weeks covered the following:
- HTML/CSS
- Ruby
- PostgreSQL
- Sinatra, irb
- Ruby on Rails
One huge draw is the fact that programming is like a game, or a puzzle. There's many ways to solve these puzzles, and you learn that some ways are faster than others, while others are more effective or clean to look at. There's a bit of joy when I go back to old code I've written, see what I've done, grin and rewrite what I could've done better now that I'm a month into the study.
I wrote some code for the zombie dictionary a few weeks back, now, and maybe when I go back to it it'll be significantly different by the end.
That said, over the weekends I'm slowly working on getting to know Vim, and while it more or less functions similarly between Unix and Windows systems, the fundamental differences between them will take me some time to adjust - for example, we utilize Homebrew, Vundle, Thoughtbot's RCM, and dotfiles to handle and manage packages, bundles and configuration settings for Vim. With the exception of Vundle which has its own set of installations for Windows, everything else is made for a UNIX system in mind. However, I'm learning of several softwares that emulate similarly. For homebrew, I've learned of chocolatey ; and quick searches for dotfile installers and bundlers for windows have turned up a few that I still need to go through.
Given this, an important thing that I learned is the core differences in how OSX handles its system-wide installations compared to Windows (which uses environmental variables to set PATHs), and the inner workings of the dotfiles we've been installing. Ultimately, it helps me understand what is being changed 'under the hood' when we brew a bundle or run RCM. (Most of the dotfiles change internal settings in Vim, Git, RailsVim and TMux among many others).
Like I said, there will be a part two for that, so that should be coming following further dives into converting from Sublime Text to Vim.
Friday 20 June 2014
Rails and Resources, Part 2
The all-important table! It's crucial this week that we have most of this table down, and honestly, I wish I wrote this blog post before our weekly quiz. Definitely would've helped!
Basically, each action here is a method defined in the table_controller.rb file (in this case, wombats). The paths are defined in the routes.rb file (under resources :wombats) in their most default state. Each path functions under a particular HTTP verb protocol. Using rails, we don't have to fully type a link in HTTP, but we can use rails code (link_to or form_for) to quickly make the connections between the records within the database (via the controller, that takes in the instances of said models with the corresponding tables based on the action used) and back within our html.erb file.The instance variable objects are basically stored references to particular database segments (such as the records we're looking for in Class.find(:id)), so when we link_to the instance variable, Rails already knows what and where we're referring to.
I know one of our classmates is working on a blogpost to fully describe the actions, so I'll be leaving this blogpost short and link to hers when she's finished.
Wednesday 18 June 2014
Rails and Resources, Part 1
This week, we began studying Rails. Compared to last week, I didn't run into any bumps between UNIX/Window differences thus far, so that was a relief. My PSQL is set up correctly (though I've yet to dig through security allowances and authentication more than I needed to - I'm almost sure that we'll be going through that, though), and I'm able to install rails with some ease.
This is probably the part that I had a few hiccups compared to the easy installs the UNIX terminals had, but this was all just because I didn't have all the installations ready.
Basically, I installed ruby, but not particular gems and additional devkits that were necessary to set things up for installing rails. Luckily, when I tried to install Rails, the error messages were -very- helpful (it's important to read them!) in pointing me at what I needed to do next. First, I needed to install JSON via gems, but then when I was told I couldn't install JSON via gems, they pointed me to make sure I had the devkit in my PATH if I installed it already. I don't think I installed the ruby devkit.
First things first, I needed to get the Ruby Devkit 's latest version. Once that was done, I ran the gem install command for the JSON version I needed (ruby gems will tell me what the exact version and command I needed once I tried to install rails on failure). After that, it was a simple matter of using 'gem install rails' and I was set.
Rails is fairly easy to comprehend, given that we spent the last week working with the stuff 'under the hood' - it makes all the things we did in Sinatra and PSQL so simple and straightforward, and there's lots of ways to shorten the process of pulling database entries onto a website.
Two of the most crucial things we had to consider however, was how the entire Rails system worked from request to response, and the other was the Seven Route Resources (tm?).
First, the Rails system from Request to Response: assuming the database is already made:
From the Browser, we make a Request to the App Server. It receives the path specified in the request, and properly routes it through a controller. The controller may instantiate the Model, which allows it to pull, change and request information from the database. From there, it renders the view based on what information it has and has been given, which becomes the response sent through the App Server and back to the Browser which displays the response, likely as an HTML file.
Browser refers to the user, or the browser who is navigating the html page and making the request.
The command 'rails s' boots up the App Server.
Routes refers to the routes.rb. It takes the Path of the url and accordingly performs the correct action via the controller.
Controller refers to the tablename_controller.rb. This is where the various actions are defined (akin to methods). What it exactly does depends on what Route is taken in the previous step. Primarily, it will set instance variables for the Model and View to use. It can pull/send database records/changes on request based on the Route via the Model, and render the View with the information it has before sending the response to the request back to the Browser. In the case of a redirect (HTTP code 3xx), it will not use Model or View and return the redirect response to the browser, which will initiate a new request to render the target URL.
Models refers to the modelname.rb file. When it gets instantiated, it's akin to using "tablename = Class.new". As classes in Rails in this case inherit ActiveRecord::Base, the object 'tablename' here is of type ActiveRecord and has access to the specific commands we use in Rails. Depending on what the controller requests, it may pull some information (.find, .where), pull all the information (.all), create a new entry (.new, .create) with the associated database table (which the Model is named after).
View refers to the .html.erb file. This is where the html.erb file containing all the text, code, and variable references are laid out. The Controller will read and render when it requests for it.
DB refers to the database.
====
Browser --request--> App Server --> [Rails Stack: Route --> read path --> Controller --> Proceed based on path:
====
Controller <--instantiates and requests based on routed path--> Model <--pull, change, create entries--> DB
AND/OR
Controller -- Reads based on route -->View --Rendered --> Controller --> App Server --returns response --> Browser
OR
Controller -- Receives redirect route --> App Server --returns response --> Browser
====
That sums up the entire process. Hopefully, this will help others understand as well. Thanks to the instructors for being patient and making this clear. Next part, I'll describe the Actions/Paths associated in the Resources in Rails.
This is probably the part that I had a few hiccups compared to the easy installs the UNIX terminals had, but this was all just because I didn't have all the installations ready.
Basically, I installed ruby, but not particular gems and additional devkits that were necessary to set things up for installing rails. Luckily, when I tried to install Rails, the error messages were -very- helpful (it's important to read them!) in pointing me at what I needed to do next. First, I needed to install JSON via gems, but then when I was told I couldn't install JSON via gems, they pointed me to make sure I had the devkit in my PATH if I installed it already. I don't think I installed the ruby devkit.
First things first, I needed to get the Ruby Devkit 's latest version. Once that was done, I ran the gem install command for the JSON version I needed (ruby gems will tell me what the exact version and command I needed once I tried to install rails on failure). After that, it was a simple matter of using 'gem install rails' and I was set.
Rails is fairly easy to comprehend, given that we spent the last week working with the stuff 'under the hood' - it makes all the things we did in Sinatra and PSQL so simple and straightforward, and there's lots of ways to shorten the process of pulling database entries onto a website.
Two of the most crucial things we had to consider however, was how the entire Rails system worked from request to response, and the other was the Seven Route Resources (tm?).
First, the Rails system from Request to Response: assuming the database is already made:
From the Browser, we make a Request to the App Server. It receives the path specified in the request, and properly routes it through a controller. The controller may instantiate the Model, which allows it to pull, change and request information from the database. From there, it renders the view based on what information it has and has been given, which becomes the response sent through the App Server and back to the Browser which displays the response, likely as an HTML file.
Browser refers to the user, or the browser who is navigating the html page and making the request.
The command 'rails s' boots up the App Server.
Routes refers to the routes.rb. It takes the Path of the url and accordingly performs the correct action via the controller.
Controller refers to the tablename_controller.rb. This is where the various actions are defined (akin to methods). What it exactly does depends on what Route is taken in the previous step. Primarily, it will set instance variables for the Model and View to use. It can pull/send database records/changes on request based on the Route via the Model, and render the View with the information it has before sending the response to the request back to the Browser. In the case of a redirect (HTTP code 3xx), it will not use Model or View and return the redirect response to the browser, which will initiate a new request to render the target URL.
Models refers to the modelname.rb file. When it gets instantiated, it's akin to using "tablename = Class.new". As classes in Rails in this case inherit ActiveRecord::Base, the object 'tablename' here is of type ActiveRecord and has access to the specific commands we use in Rails. Depending on what the controller requests, it may pull some information (.find, .where), pull all the information (.all), create a new entry (.new, .create) with the associated database table (which the Model is named after).
View refers to the .html.erb file. This is where the html.erb file containing all the text, code, and variable references are laid out. The Controller will read and render when it requests for it.
DB refers to the database.
====
Browser --request--> App Server --> [Rails Stack: Route --> read path --> Controller --> Proceed based on path:
====
Controller <--instantiates and requests based on routed path--> Model <--pull, change, create entries--> DB
AND/OR
Controller -- Reads based on route -->View --Rendered --> Controller --> App Server --returns response --> Browser
OR
Controller -- Receives redirect route --> App Server --returns response --> Browser
====
That sums up the entire process. Hopefully, this will help others understand as well. Thanks to the instructors for being patient and making this clear. Next part, I'll describe the Actions/Paths associated in the Resources in Rails.
Sunday 15 June 2014
Working with some people
I deal with quite a handful of people as moderator of an online collaborative writing group. My job is to make sure folks in the group are happy and other groups we interact with are satisfied with us. There's a couple of other things along with that to boot, but the long and the short of it is I have to speak to people within and without of my group. And sometimes, the things I have to deal with are pretty outlandish.
I've written a general post that more or less sums up a gist of the issue:
I've written a general post that more or less sums up a gist of the issue:
"When you're in common society, you're faced with several choices. Among these choices is to avoid getting stigmatized as a result of your own actions. Maybe it was an accident, or maybe a cause of ignorance, or maybe you just didn't care, but you end up branded with negative labels.
Keeping that in mind, when you attach a stigma to someone yourself, you're part of the problem. It's even MORE depressing to see that stigma spread and persist for years without looking at that person a second time and keeping your head down (or nose up, depending on what kind of stigma you're attaching). What's MOST depressing is to see that when you yourself are pointed out to be part of the problem for not doing something sooner and just covering your ears, your response is to be irresponsible and deflect, ignore, play the victim and say that the person with the stigma deserves it for their actions. No matter how many times you get acknowledgement that the stimga-ee (is that even a word?) is indeed at fault, you will not take the part-blame for perpetuating the problem. By not seeing how your past years of loathing of the person for whatever reason has prevented you from being unbiased in your approaches, you failed to cut the problem when it was relevant. At the time, you felt that it was best you deal with the issue yourself - but what did you do exactly? And what was the result of that? If you're unhappy with your inaction, you end up blaming the stigmatized - yes, the one you attached yourself and continued to spread it among other people.
But that's human beings for you right there. :P But moral of the story, avoid the stigma, but don't label and perpetuate it. And don't let other people paint the stigma for you. For the love of God and the universe, don't let other people paint your perceptions of a person or party."
Thursday 12 June 2014
Coding on Windows in a UNIX-heavy class, Part 1
Part 1 because I am sure I'll be writing more about this down the line.
Most of the class in Metis is taught using Mac OSX. I've quickly learned that many and most programmers use Mac OSX, LINUX and other unix platforms (at least, among those I've seen in my stay in Boston). Developing on Windows is pretty unpopular - this much I've been told by people I've spoken to.
I've been loaned a mac prepared and ready for use by Metis, as I've brought my Windows 7 laptop along to the course (most of those in the course and the instructors are most familiar and are using Macbooks). I'm familiar with Macs, I've used them every now and then in University, but I was born and raised on Windows. Feeling like I can keep up despite the OS differences, I decide to stay on the Windows while bringing the Mac with me just in case it proves too much.
Week 1, there wasn't much of a difference. Week 2, we've begun work on SQL, ruby gems, multiple ruby versions, etc. and there are tons of UNIX specific programs and commands that my Windows didn't have. Being the only windows user in the class, the pressure was high for me to just boot up the Mac - but I decided to keep pressing on. It required a lot of googling during the lecture itself, and even making sure I was ready before the classes even start.The instructors are able to help if I asked though (the godsend of having 2 at once), but I feel like that I should be able to overcome any issues from my choice on my own.
I have to say: it was a little nervewracking, but it's a feeling I'll have to get used to. I have to make sure I could catch what was being taught in the lectures while at the same time searching for many solutions to whatever thing I needed to do. Once I was on the same page, there was a terse feeling of relief - I wasn't sure when the next time the software would do something unexpected from what was explained and I had to fix it up myself.
Summing up what was taught in the last few days - I'll write a more detailed post later - but we started the week with PostgreSQL. I first installed PSQL with the following links' assistance. It's important to make sure it works and verify that it works on pgAdminIII (easiest way to check. The instructions make it clear):
PostgreSQL for Windows
PostgreSQL Installation tutorial
Once it works out, PSQL should work on your command prompt. You can open git or cmd (I'll set up Vim later in the week) and type:
Now, when I type it out, it asks me for a password (which you establish when you first install psql). However, when I enter anything, it says I've given a wrong password for my user. I think this has to do with the installer I use (hours of googling reveal that not everyone can face this issue) and certainly the others in the class didn't have this problem. So what happened?
Either it was some sort of PC configuration or just how I installed it, the PSQL user profile postgres isn't the default one set when using the psql command in prompt or git - thus it defaults to inputting my computer user profile as the one accessing the psql command. That's not exactly what I want, so I have to specify who's using it (using the installed PSQL shell that came in with the PSQL installation though, by default uses the postgres superuser for accessing the database). The --help command, that is:
Is immensely useful because it lists all the other commands and arguments you can attach to psql. So, to access psql, I can use
in command prompt/git, will let me specify the username to postgres. Then, it will ask me for a password, after putting it in I will have access to the database. By default, the database is postgres - so if I made a new database photo-gallery I have to specify the database:
One password input later, I'm in the photo-gallery database. That's great and all, though it gets annoying every time to input the user name and password (and in one instance using psql, I found that my password input isn't masked, which is a huge gasp. I've googled for fixes and ways to simplify the process to make it similar to how the Macs seem to have no issue entering/exiting/doing postgres commands, and there's a few suggestions. I'll get more indepth once I commit to a choice on how in another post, but these are the gist of the solutions:
-Make an alias that automatically inputs the username postgres each time
-Edit the authentication process for users that aren't postgres as well as password input
-Just use a linux-emulator (I'll describe this later)
-Adjust a configuration
Again, maybe it's just how my computer is set up, but none of those are straight forward. The other issue is, when you google for a solution, 80% of the solutions, if I don't specify for it, are for OSX/Linux/Ubuntu, not for Windows OS. Another issue is, there are 4-5 different answers on stackoverflow (a godsend of a resource next to programming documentation), but most of them aren't really much in the way of instructions (they assume you know your stuff most of the time,) so you google for particular things in those instructions and so on until you get what you want. Making aliases on git,the way its set up for me doesn't seem to work (I'll be googling to find where the config file it loads from is located) because there seems to be 2-3 different config files (according to the results I'm getting at stack overflow).
Similarly with psql. There's many ways to fix the issue in adjusting configuration, it seems, which is nice and all - though all of them seem to carry some kind of security concern - which is probably much clearer the more I learn about databases, how remote connections connect to my database, etc will allay any fears I have (Hence, why this is part 1). There's neat blogs and pages that explain the important types of security authentication for databases that I'll be reading into for when I get in-depth.
That said, I found a nifty little blog by someone familiar with the installer I used that explains a little about this issue on psql via EnterpriseDB: Dave's Postgres Blog
But enough about psql; there are other things that I had to do googles for mid-lecture and that was for a way to change ruby versions that are installed on your computer. For Mac OSX, they used Chruby and rvm; for Windows, I found pik.
Pik mimics a lot of commands that rvm and chruby does - we haven't used it substantially, but I have it ready (and it's important to make sure it is). By default, when installed pik only works on command prompt, not git; and it goes back to finnagling one of the config files for git to get pik commands to work on it.
While it is possible to install pik using ruby gems, I did an install through the .msi file on pik's GitHub page. Again, it might be with how I installed my ruby (I installed x64 version of Ruby 2.0.0, but installing pik via the gem only gave me pik 0.2.8 whereas the latest version was 0.3), but at the end of the day, I had to edit my %PATH% environment variables to make sure pik properly worked. It's important to understand Environment_Variables on windows and making sure I knew my %PATH% and what it does so I can be sure that things can work (it's crucial in trying to make sure your PC functions when you install new programs through prompt, etc.)
I'll probably touch on pik and %PATH% a lot more when we actually start using rvm/chruby in class, however. But I got mine working to a point where I can change ruby versions.
That's about it for this post; however there are some very crucial pages I'm keeping tabs on. The first is a page for Windows and Unix equivalents ! It's pretty important. There's several terminal commands on UNIX based consoles referenced in class which are essentially synonyms for what Windows uses. It's a good cheat sheet to have and look through. The other is a linux emulator, Cygwin . I came across this while searching for ways to change ruby versions on windows and a post described using Cygwin to use rvm on a windows PC. I didn't really read into it, but it'll be a good thing to turn to in case I ever find something on UNIX that is not yet replicable in a Windows environment.
Most of the class in Metis is taught using Mac OSX. I've quickly learned that many and most programmers use Mac OSX, LINUX and other unix platforms (at least, among those I've seen in my stay in Boston). Developing on Windows is pretty unpopular - this much I've been told by people I've spoken to.
I've been loaned a mac prepared and ready for use by Metis, as I've brought my Windows 7 laptop along to the course (most of those in the course and the instructors are most familiar and are using Macbooks). I'm familiar with Macs, I've used them every now and then in University, but I was born and raised on Windows. Feeling like I can keep up despite the OS differences, I decide to stay on the Windows while bringing the Mac with me just in case it proves too much.
Week 1, there wasn't much of a difference. Week 2, we've begun work on SQL, ruby gems, multiple ruby versions, etc. and there are tons of UNIX specific programs and commands that my Windows didn't have. Being the only windows user in the class, the pressure was high for me to just boot up the Mac - but I decided to keep pressing on. It required a lot of googling during the lecture itself, and even making sure I was ready before the classes even start.The instructors are able to help if I asked though (the godsend of having 2 at once), but I feel like that I should be able to overcome any issues from my choice on my own.
I have to say: it was a little nervewracking, but it's a feeling I'll have to get used to. I have to make sure I could catch what was being taught in the lectures while at the same time searching for many solutions to whatever thing I needed to do. Once I was on the same page, there was a terse feeling of relief - I wasn't sure when the next time the software would do something unexpected from what was explained and I had to fix it up myself.
Summing up what was taught in the last few days - I'll write a more detailed post later - but we started the week with PostgreSQL. I first installed PSQL with the following links' assistance. It's important to make sure it works and verify that it works on pgAdminIII (easiest way to check. The instructions make it clear):
PostgreSQL for Windows
PostgreSQL Installation tutorial
Once it works out, PSQL should work on your command prompt. You can open git or cmd (I'll set up Vim later in the week) and type:
psqlNow, when I type it out, it asks me for a password (which you establish when you first install psql). However, when I enter anything, it says I've given a wrong password for my user. I think this has to do with the installer I use (hours of googling reveal that not everyone can face this issue) and certainly the others in the class didn't have this problem. So what happened?
Either it was some sort of PC configuration or just how I installed it, the PSQL user profile postgres isn't the default one set when using the psql command in prompt or git - thus it defaults to inputting my computer user profile as the one accessing the psql command. That's not exactly what I want, so I have to specify who's using it (using the installed PSQL shell that came in with the PSQL installation though, by default uses the postgres superuser for accessing the database). The --help command, that is:
psql --helpIs immensely useful because it lists all the other commands and arguments you can attach to psql. So, to access psql, I can use
psql -U postgresin command prompt/git, will let me specify the username to postgres. Then, it will ask me for a password, after putting it in I will have access to the database. By default, the database is postgres - so if I made a new database photo-gallery I have to specify the database:
psql photo-gallery -U postgres One password input later, I'm in the photo-gallery database. That's great and all, though it gets annoying every time to input the user name and password (and in one instance using psql, I found that my password input isn't masked, which is a huge gasp. I've googled for fixes and ways to simplify the process to make it similar to how the Macs seem to have no issue entering/exiting/doing postgres commands, and there's a few suggestions. I'll get more indepth once I commit to a choice on how in another post, but these are the gist of the solutions:
-Make an alias that automatically inputs the username postgres each time
-Edit the authentication process for users that aren't postgres as well as password input
-Just use a linux-emulator (I'll describe this later)
-Adjust a configuration
Again, maybe it's just how my computer is set up, but none of those are straight forward. The other issue is, when you google for a solution, 80% of the solutions, if I don't specify for it, are for OSX/Linux/Ubuntu, not for Windows OS. Another issue is, there are 4-5 different answers on stackoverflow (a godsend of a resource next to programming documentation), but most of them aren't really much in the way of instructions (they assume you know your stuff most of the time,) so you google for particular things in those instructions and so on until you get what you want. Making aliases on git,the way its set up for me doesn't seem to work (I'll be googling to find where the config file it loads from is located) because there seems to be 2-3 different config files (according to the results I'm getting at stack overflow).
Similarly with psql. There's many ways to fix the issue in adjusting configuration, it seems, which is nice and all - though all of them seem to carry some kind of security concern - which is probably much clearer the more I learn about databases, how remote connections connect to my database, etc will allay any fears I have (Hence, why this is part 1). There's neat blogs and pages that explain the important types of security authentication for databases that I'll be reading into for when I get in-depth.
That said, I found a nifty little blog by someone familiar with the installer I used that explains a little about this issue on psql via EnterpriseDB: Dave's Postgres Blog
But enough about psql; there are other things that I had to do googles for mid-lecture and that was for a way to change ruby versions that are installed on your computer. For Mac OSX, they used Chruby and rvm; for Windows, I found pik.
Pik mimics a lot of commands that rvm and chruby does - we haven't used it substantially, but I have it ready (and it's important to make sure it is). By default, when installed pik only works on command prompt, not git; and it goes back to finnagling one of the config files for git to get pik commands to work on it.
While it is possible to install pik using ruby gems, I did an install through the .msi file on pik's GitHub page. Again, it might be with how I installed my ruby (I installed x64 version of Ruby 2.0.0, but installing pik via the gem only gave me pik 0.2.8 whereas the latest version was 0.3), but at the end of the day, I had to edit my %PATH% environment variables to make sure pik properly worked. It's important to understand Environment_Variables on windows and making sure I knew my %PATH% and what it does so I can be sure that things can work (it's crucial in trying to make sure your PC functions when you install new programs through prompt, etc.)
I'll probably touch on pik and %PATH% a lot more when we actually start using rvm/chruby in class, however. But I got mine working to a point where I can change ruby versions.
That's about it for this post; however there are some very crucial pages I'm keeping tabs on. The first is a page for Windows and Unix equivalents ! It's pretty important. There's several terminal commands on UNIX based consoles referenced in class which are essentially synonyms for what Windows uses. It's a good cheat sheet to have and look through. The other is a linux emulator, Cygwin . I came across this while searching for ways to change ruby versions on windows and a post described using Cygwin to use rvm on a windows PC. I didn't really read into it, but it'll be a good thing to turn to in case I ever find something on UNIX that is not yet replicable in a Windows environment.
Sunday 8 June 2014
Revisiting the past
I mentioned in the last post that I really started reading code (Ruby, anyway) through RPG Maker XP, or RMXP for short. The programs that followed, developed also by Enterbrain was RMVX and RMVXA (RPG Maker VX and VX Ace). Today, I decided to spend a short while in the afternoon to revisit that.
Lo and behold, a script among many others from the software default library:
Just earlier in the year, these words made very little sense to me. I used to just try and piece things together where I can and if I need to modify something, more often than not it's on a custom-made script by other programmers (who upload a free-use script for use in RPG Maker or sometimes commercial license required scripts) and they use Constants (Now I know the right term!) that users of the scripts are allowed to adjust according to the users' needs. But now, I can read the meat of the scripts very well!
Essentially, Scenes in RGSS (the name of RPG Maker's library for ruby) refer to windows that players will be seeing in the game - which are classes. In this case, Scene_Save refers to the save game screen when players want to save their game. And now, I can break this down bit by bit.
Scene_Save is a class, and it inherits Scene_File class (Makes sense, because Scene_File, a much bigger script handles the write/load procedure of saving and loading games, which its subclasses (Scene_Load, Scene_Save) will use.As a class, Scene_Save will have many methods inside it - and now I see that there are many methods("help_window_text", "on_savefile_ok") and constants being called within those methods itself. And knowing the software as long as I have, I know what those constants refer to! This particular script now makes tons of sense.
In the past week, I've been wondering why when we learned reading/writing files we used one script that had the class handling the read/write method and another script that actually called the methods - but seeing them in action in RMVXA really made it that much clearer why they'd do that. It's cleaner, easier to see - far better than putting everything on one script. It's also because in this instance we have 3 different windows that the user will interact with in the game, which is the File Scene/Window, which asks them if they want to Save/Load so they can make a choice if they want to open either of those scenes. Then, Scene_File handles most of the read/write processes while Scene_Save/Scene_Load just creates the windows for user interaction. It's important because if we want to override any of these with a custom script, it's so much easier to just override the class Scene_Save and Scene_Load (Which custom Save/Load mods DO target if they just want to change the general layout) or Scene_File (where they change -how- games are saved and loaded, such as directory, information actually recorded, etc.).
I look forward to actually using the built-in scripts as well as custom scripts to further learn as a case study for Ruby scripts in the future.
Lo and behold, a script among many others from the software default library:
#==============================================================================
# ** Scene_Save
#------------------------------------------------------------------------------
# This class performs save screen processing.
#==============================================================================
class Scene_Save < Scene_File
#--------------------------------------------------------------------------
# * Get Help Window Text
#--------------------------------------------------------------------------
def help_window_text
Vocab::SaveMessage
end
#--------------------------------------------------------------------------
# * Get File Index to Select First
#--------------------------------------------------------------------------
def first_savefile_index
DataManager.last_savefile_index
end
#--------------------------------------------------------------------------
# * Confirm Save File
#--------------------------------------------------------------------------
def on_savefile_ok
super
if DataManager.save_game(@index)
on_save_success
else
Sound.play_buzzer
end
end
#--------------------------------------------------------------------------
# * Processing When Save Is Successful
#--------------------------------------------------------------------------
def on_save_success
Sound.play_save
return_scene
end
end
Just earlier in the year, these words made very little sense to me. I used to just try and piece things together where I can and if I need to modify something, more often than not it's on a custom-made script by other programmers (who upload a free-use script for use in RPG Maker or sometimes commercial license required scripts) and they use Constants (Now I know the right term!) that users of the scripts are allowed to adjust according to the users' needs. But now, I can read the meat of the scripts very well!
Essentially, Scenes in RGSS (the name of RPG Maker's library for ruby) refer to windows that players will be seeing in the game - which are classes. In this case, Scene_Save refers to the save game screen when players want to save their game. And now, I can break this down bit by bit.
Scene_Save is a class, and it inherits Scene_File class (Makes sense, because Scene_File, a much bigger script handles the write/load procedure of saving and loading games, which its subclasses (Scene_Load, Scene_Save) will use.As a class, Scene_Save will have many methods inside it - and now I see that there are many methods("help_window_text", "on_savefile_ok") and constants being called within those methods itself. And knowing the software as long as I have, I know what those constants refer to! This particular script now makes tons of sense.
In the past week, I've been wondering why when we learned reading/writing files we used one script that had the class handling the read/write method and another script that actually called the methods - but seeing them in action in RMVXA really made it that much clearer why they'd do that. It's cleaner, easier to see - far better than putting everything on one script. It's also because in this instance we have 3 different windows that the user will interact with in the game, which is the File Scene/Window, which asks them if they want to Save/Load so they can make a choice if they want to open either of those scenes. Then, Scene_File handles most of the read/write processes while Scene_Save/Scene_Load just creates the windows for user interaction. It's important because if we want to override any of these with a custom script, it's so much easier to just override the class Scene_Save and Scene_Load (Which custom Save/Load mods DO target if they just want to change the general layout) or Scene_File (where they change -how- games are saved and loaded, such as directory, information actually recorded, etc.).
I look forward to actually using the built-in scripts as well as custom scripts to further learn as a case study for Ruby scripts in the future.
Friday 6 June 2014
Friday Challenge - ZOMBIES!
Today at Metis is a friday, and fridays are basically 'do whatever you want days'.
For me, this is fixing up the blog, and doing a few of our programming challenges. We also had a talk by Ben Orenstein about the things we as budding programmers should consider for our future. Very informative, very helpful!
So: the programming challenges vary in difficulty. Some are fairly easy (such as summing up all fibonacci numbers up to 4 million):
But even with how I managed to get what I needed, I'm positive there's better ways to write that code. That's part of what we're taught at Metis - the importance of refactoring and keeping code clean and easy to read.
That said, the real difficulty comes in the form of this particular challenge. In short, it's trying to make sense of what seems like plain gibberish (zombie speech, according to the scenario), by loading up various scenarios that contain a dictionary and looking up zombie garble to check if the words are a match, then suggest if that was what the zombie was implying. We had an input file, with a few numbers, then a list of words, then a number, then a list of words, and so on for the rest of the number of scenarios. The numbers either described the number of scenarios, the number of the words that would come after the number, and the number of zombie garble that would come after it. It's a bit of a confusing file to read at the start.
Here's a snippet of what was 4 hours of work:
It had a LOT of forms before it came to this. All this ends up doing is loading up words in each scenario, shoving it into specific variables in a specified order (The .zombies.in file is written in such a way that this is necessary, part of the challenge) so I had to create a loop to make sure I got every word in the dictionary and every zombie garble into a list for each scenario before it moves on to the next one.
It hasn't done any of the features it needs to after the fact, but for now it was VERY satisfying to see it run after awhile. A few things that I learned:
The .readlines command - incredibly helpful because it turns your entire file into an array of strings. Now, the array had some strings that contained some numbers, which posed issues unless I knew exactly when the numbers would come (so I can safely predict and use .to_i - which I did!). You can't call .times on these strings without calling .to_i. And initially I used .is_a? Integer to check what type of element the current line was reading, but when the loop failed, that's when I found out .readlines returns an array of strings.
So, in short, integers are really wonky and hard to work with when they're already strings, so you have to be very creative. X.x
Here's to hoping tomorrow I can finish the rest of the program!
For me, this is fixing up the blog, and doing a few of our programming challenges. We also had a talk by Ben Orenstein about the things we as budding programmers should consider for our future. Very informative, very helpful!
So: the programming challenges vary in difficulty. Some are fairly easy (such as summing up all fibonacci numbers up to 4 million):
class Fibonacci
def initialize
@num_interim = 0
@total_sum = 0
@num_1 = 1
@num_2 = 2
end
def fib_sequence(limit)
until @num_interim >= limit
@num_interim = @num_1 + @num_2
@num_1 = @num_2
@num_2 = @num_interim
seq_check
end
puts @total_sum
end
def seq_check
if @num_interim % 2 == 0
@total_sum += @num_interim
end
end
end
wombat = Fibonacci.new
wombat.fib_sequence(4000000) But even with how I managed to get what I needed, I'm positive there's better ways to write that code. That's part of what we're taught at Metis - the importance of refactoring and keeping code clean and easy to read.
That said, the real difficulty comes in the form of this particular challenge. In short, it's trying to make sense of what seems like plain gibberish (zombie speech, according to the scenario), by loading up various scenarios that contain a dictionary and looking up zombie garble to check if the words are a match, then suggest if that was what the zombie was implying. We had an input file, with a few numbers, then a list of words, then a number, then a list of words, and so on for the rest of the number of scenarios. The numbers either described the number of scenarios, the number of the words that would come after the number, and the number of zombie garble that would come after it. It's a bit of a confusing file to read at the start.
Here's a snippet of what was 4 hours of work:
def read_file
File.open("./zombies.in", "r") do |file|
#get number of scenarios
@input_file = file.readlines
set_scenario_number
until @current_scenario == @scenario
if @word_number == 0
set_number_words
elsif @garble_number == 0
set_number_garble
else
next_scenario
end
puts "Currentline is now #{@currentline}"
end
end
end
It had a LOT of forms before it came to this. All this ends up doing is loading up words in each scenario, shoving it into specific variables in a specified order (The .zombies.in file is written in such a way that this is necessary, part of the challenge) so I had to create a loop to make sure I got every word in the dictionary and every zombie garble into a list for each scenario before it moves on to the next one.
It hasn't done any of the features it needs to after the fact, but for now it was VERY satisfying to see it run after awhile. A few things that I learned:
The .readlines command - incredibly helpful because it turns your entire file into an array of strings. Now, the array had some strings that contained some numbers, which posed issues unless I knew exactly when the numbers would come (so I can safely predict and use .to_i - which I did!). You can't call .times on these strings without calling .to_i. And initially I used .is_a? Integer to check what type of element the current line was reading, but when the loop failed, that's when I found out .readlines returns an array of strings.
So, in short, integers are really wonky and hard to work with when they're already strings, so you have to be very creative. X.x
Here's to hoping tomorrow I can finish the rest of the program!
This is Metis
Last post I said what a crazy week it's been, this week is still crazy.
So I'm part of Metis, a ruby-on-rails webdev/programming bootcamp. I didn't know what to expect when I first put in my application months ago; someone had recommended to me following my degree I try programming, and then I got forwarded the application website.
That's what started this entire trip, and now I'm in Boston, MA. This is my 2nd week in the States, and I've just gone through the first week of classes.
I'm not new to programming. I think my earliest programming history -truly- started when I fiddled around with my computer's ins and outs. The idea was that I understood how a computer would think. I started modding games, understanding the ways how programs, or maybe even just how windows parses information. Very simple, very outside stuff, no real coding yet.
Then I started to play with my first 'code', which is event-based scripting in RPG Maker 2000. It was a program of sorts, easy to use, intuitive UI. Confusing at first, but to simplify the software to those who aren't familiar with it, it essentially lets you script out processes in an old-school-esque game (2D, top down, sprite RPGs) on events (which are kind of like objects), using predefined methods (such as moving the event, opening a chat box on interacting with the event in game, altering game parameters such as character levels or items after interacting) that can be chained in a sequence. This is essentially programming - sequencing a bunch of code to make something happen.
It's in a nice little package, but several RPG Makers later till RMXP, I've been fiddling on and off, trying out freely available games on the web, editing them and adding onto them as I saw fit, playing with the tools, creating my own projects and expressing my (then-very-cheesy-plots-based) creativity. I even beta-tested and contributed to Solest Games' Master of the Wind - a huge project that was 7 years in the making by 2 guys; and even today I am helping where I can with their latest venture (after they had just released another game commercially on Steam). Using the maker's built in RGSS system which is based on Ruby, people can significantly alter the games with scripts that override the default systems or even create new systems. I didn't code too much but this was when I started reading parameters and elements, and changing a few things where I could to fit custom-scripts made by people to my needs for any sandbox game I was trying out or debugging.
Following and around this I looked into modding Bethesda Games' Fallout and The Elder Scrolls games, and debugging is a huge process for anyone trying to load 100+ mods into their game. When TESV: Skyrim's Creation Kit came out in 2011/2012, I jumped on the ship and tried to make my functioning, but incomplete mod during University. The CK used Papyrus, which I believe is a modified version of Java or JavaScript. It was probably the first time I seriously tried to write real code - and as clunky of a software as it was, there were many good 'eureka' moments when something went right. I really enjoyed spending nights coding instead of actually studying when I was on a high - it felt good to create something.
That summed up the programming experience I had, besides coding few scripts and lines in R and SAS for statistics analysis in University for my science degrees (By that point, code syntax had become pretty familiar to me, no matter the language). Months after the application, a few codeacademy lessons later, I've finally arrived to the course.
The first week was -great-. It's a small class, less than 15 people, with 2 fantastic and patient instructors. The course is aimed at people with little to no background in programming, and while I feel that I and a few others have a bit of a leg up in the first week, I think everyone else is catching up to where I am. Even though I think I grasped everything fairly well, I still make mistakes, and I still get baffled by programming challenges - which is fair, considering how I've never done any kind of proper code. I -can- write some code, but the cool thing at Metis is how they teach me how to do things efficiently and properly, which is really important in the world where things are mostly open-source and people code together.
It's a fantastic place to be, and week 1 is coming to a close. I'll be putting up some code on some of the challenges I've bee doing, including the challenges I've been facing. Here's to a good 12 weeks!
So I'm part of Metis, a ruby-on-rails webdev/programming bootcamp. I didn't know what to expect when I first put in my application months ago; someone had recommended to me following my degree I try programming, and then I got forwarded the application website.
That's what started this entire trip, and now I'm in Boston, MA. This is my 2nd week in the States, and I've just gone through the first week of classes.
I'm not new to programming. I think my earliest programming history -truly- started when I fiddled around with my computer's ins and outs. The idea was that I understood how a computer would think. I started modding games, understanding the ways how programs, or maybe even just how windows parses information. Very simple, very outside stuff, no real coding yet.
Then I started to play with my first 'code', which is event-based scripting in RPG Maker 2000. It was a program of sorts, easy to use, intuitive UI. Confusing at first, but to simplify the software to those who aren't familiar with it, it essentially lets you script out processes in an old-school-esque game (2D, top down, sprite RPGs) on events (which are kind of like objects), using predefined methods (such as moving the event, opening a chat box on interacting with the event in game, altering game parameters such as character levels or items after interacting) that can be chained in a sequence. This is essentially programming - sequencing a bunch of code to make something happen.
It's in a nice little package, but several RPG Makers later till RMXP, I've been fiddling on and off, trying out freely available games on the web, editing them and adding onto them as I saw fit, playing with the tools, creating my own projects and expressing my (then-very-cheesy-plots-based) creativity. I even beta-tested and contributed to Solest Games' Master of the Wind - a huge project that was 7 years in the making by 2 guys; and even today I am helping where I can with their latest venture (after they had just released another game commercially on Steam). Using the maker's built in RGSS system which is based on Ruby, people can significantly alter the games with scripts that override the default systems or even create new systems. I didn't code too much but this was when I started reading parameters and elements, and changing a few things where I could to fit custom-scripts made by people to my needs for any sandbox game I was trying out or debugging.
Following and around this I looked into modding Bethesda Games' Fallout and The Elder Scrolls games, and debugging is a huge process for anyone trying to load 100+ mods into their game. When TESV: Skyrim's Creation Kit came out in 2011/2012, I jumped on the ship and tried to make my functioning, but incomplete mod during University. The CK used Papyrus, which I believe is a modified version of Java or JavaScript. It was probably the first time I seriously tried to write real code - and as clunky of a software as it was, there were many good 'eureka' moments when something went right. I really enjoyed spending nights coding instead of actually studying when I was on a high - it felt good to create something.
That summed up the programming experience I had, besides coding few scripts and lines in R and SAS for statistics analysis in University for my science degrees (By that point, code syntax had become pretty familiar to me, no matter the language). Months after the application, a few codeacademy lessons later, I've finally arrived to the course.
The first week was -great-. It's a small class, less than 15 people, with 2 fantastic and patient instructors. The course is aimed at people with little to no background in programming, and while I feel that I and a few others have a bit of a leg up in the first week, I think everyone else is catching up to where I am. Even though I think I grasped everything fairly well, I still make mistakes, and I still get baffled by programming challenges - which is fair, considering how I've never done any kind of proper code. I -can- write some code, but the cool thing at Metis is how they teach me how to do things efficiently and properly, which is really important in the world where things are mostly open-source and people code together.
It's a fantastic place to be, and week 1 is coming to a close. I'll be putting up some code on some of the challenges I've bee doing, including the challenges I've been facing. Here's to a good 12 weeks!
Subscribe to:
Posts (Atom)