New project (may 5-9)

For this week, because Thrill jockey is on stand by I worked into a new project called Starprog, in this one, I’m working into the blackjack game. In this I started from the basics, creating the models, relations and go on from there. In this case I started testing everything, now I’m learning a lot about tests and its benefits.

I did the card assignment, make the view  work with the new code, update the bet quantity, and the checking if there is a winner, when is a blackjack. I need to do test to part of the code that was already there, and some actions on blackjack controller.

On eventwax, I fixed the 2 issues that were found about the ckeditor implementation. Also I did tests which threw some styles issues on IE’s browsers. So  I spent the whole day doing that. At the end of the day I was checking how formtastic works, that is a tool to generate forms, and it is used on this site. But after all, a coworker told me that it would be better if for this story I get rid of this, because formtastic cant be adapted to much in the way that in rails there is the phrase “convention over configuration”, so he told me that it would be faster, and easier to do it in a “manual” way.

Lessons, we need them to learn.(april 28th -may 2nd)

This week there was no too much work on Thrill Jockey, in fact we are again on stand by. The guy in front on the team, assigned me to research about the shipping and see the viability of using the gem active shipping, so I installed that gem, and tried to set it up for Thrill Jockey, at the end, I got to the point that if we use it, we still need to customize it, changing its code.

It is because this uses a weight, dimensions and the other data for a whole product, not for each product variant that is what we need. If we don’t have variants the problem will be data duplication.

On the other hand, on eventwax, I just worked a day because it was a holiday.So I started working into a big story that is called redesign add an event. I started with the logo image upload, this story is a big challenge because it implies the use of a lot of things changing a lot, and also I need to take into consideration that I cant use any gem because it needs to work with the current environment rails 2.3 and ruby 1.8.

All is about communication with the client(21-25th april)

Finally after a week we got the feedback from the client and two stories on the working column. This week I worked on php, in the part of the record crate making a user able to download the digital content purchased, so that when he or she clicks on the download bottom a zip file with the content was generated so that he/she can obtain the digital content.

Also we review and estimate some of the next stories , in which the acceptance criteria was understandable. I upload that order-processing story to the server so that the designer can review it, and test it.

On Eventwax, there was a high priority bug on production, so I spent the whole time fixing it fortunately we were able to fix it. The problem was that  2 people on the same computer on eventwax site made two different purchases one had trouble and the second no, but the payment was assigned to the one with trouble(that was known that she did not made the payment).

We review the logs of the server, and we saw and found the problem there, at the end, was a bug with the sessions, that were not being cleared properly. So that was the big learning of the week was the session’s management, security issues are again really important. That was a specific case when 2 different users made tickets purchase on the same computer and browser, but it make it visible a huge security issue.

Sometimes we need to take a step back (14-16 april)

For this week, there was no much programming on Thrill Jockey project, what we did was to finish a proposal with the stories that we know that are missing on that project, so that we can go faster instead of be waiting for the to write one. Moreover we had a meeting, and we got an agreement, we are not going to do anything until we got an approval from them and from a guy that built part of the current site.

So, that week on TJ I did the set up of the payment gateways Paypal y First Data. I did not use the paypal set up that spree provides because it did not work. After a research I did I found a gem called Paypal Express, so I learnt about the set up of that payment gateway, I created a sandbox and test accounts to be able to do purchases with this payment gateway.

On the other hand for First Data the set up was really easy, I used the one that spree provides, the challenge here was to create a test account, because for this we need to get a store number, a PEM that is a private key and also a tax id.

Because I finished that on Tuesday, on Wednesday I did pairing with a coworker, and we were working on tests with rspec. I did the firsts real tests to models. So for this week I learnt about payment gateways configuration and started with tests on rspec. With the payment gateways is really important to know how to set them and which to use, we are talking about money so we need to be sure that we have the highest security on this. And for rspec, it is a good habit that I need to acquire, tests can benefit a lot, for multiple reasons some of them are: you just code what you need, if you make a change on some part of the code, if you run the test suite you can check if the behavior in some part was change it and we can prevent future bugs.

Week apr 7 - apr 11

For this week I worked 3 days on eventwax, the site for events management and on thursday I wrote a stories proposal document for other project Thrill Jockey. Basically this week on eventwax was about to continue with the integration of a editor to the description fields of the event's creation, so that it would be nice for the users to change the styles and make it look better.

So, I worked on the integration of the ckeditor into the site, which was successful. At the beginning it was a complete headache because I  did not  know anything but after a research it  was a easy as to downloads the ckeditor folder with the js files, locate it into the javascript folder into the the project, and add the script call to the views that will use it.

After that integration I found that some features were not working properly, so we told that to the client, and what he said was that what he want us to do is just to quit those features that are not working, and that's what I'll be working after easter. Also for this week there were 2 bugs that needed to be fixed ASAP  so I also fixed those 2 bugs, they were about meet DRY (Dont repeat yourself) and a problem with a validation of an event's capacity.

Finally on Thrill Jockey, I worked writing the stories that are missing to do a proposal to the client, from that we saw that there is still work missing but that is not too much. On this week I learned to integrate the ckeditor on a rails app, also apply DRY, and about validations on rails. On the other side for TJ I learned that proposals need to be very detailed, everything needs to be understandable to every person knowing about programming or not needs to understand it.

Week march 31 - apr 4

For this week the project still continues on stand by, however there was a meeting to get information, and try to  make alive the project again. Also I continue with the solitaire game and eventwax project.

On Thrill Jockey project we went to a meeting were we got a bunch of information, the team show us how they manage the Catalog, Press and Artist part, that is because the client said that she  wants to reuse that part from the rails app that was build before. So, we spent a whole afternoon getting info about it.

The conclusions we got from that is that, most of the site is just to display info, so if we use it still we need to code a lot of functionality. So, the next step took was to create a document to explain the structure and mark  possible new stories.

As part of the work of the week we finish the part of the solitaire that was assigned, and started doing the first real tests. This was really hard, I could not got the trick, so I need to finish the rspec book. Also, we started the introduction to phone gap, I did a hello world with that and the next step is to try to pass a simple rails app into it.

Finally on eventwax I worked including the ckeditor to the add an event functionality on the description. It took too much time, but finally it worked. I did not need the installation fo any gem, just to download the files and add them to the public/javascripts folder and add the class to the component that was going to use it with a function that activates it. That was a really interesting learning of the week, sometimes we think that the easiest way to add a component is to add a gem, however this was not the case.

Also on eventwax, we wrote the stories in which we broke the redesign add an event story to make them more manageable. I started changing the template to make it look as the client wants.

Week Mar 24 - 28

For this week our project was on stand by. But we use this time to start another project and keep working on event wax. During the day with the help and guidance of a coworker we work on a solitaire on rails from scratch. That make me learn how to build the ruby-version and the ruby-gemset files, also how to make the models,controllers and views without the rails generate command and finally the basics about relations between tables on models.

On the other hand on eventwax I worked analysing rake tasks about invoicing and got feedback from the client about the new story that my coworker and I are going to start. Basically what I did on the analysis of the tasks  was to go method by method to understand what was the problem, with the techlead we got to the conclusion that the problem of repeated invoices was external to the code, in fact we got an email of the client saying that the command was run twice and that  caused the error. 

However there are some inefficiencies that the client wants to quit from the code, so I'm still working with that trying to find out a way to make it more efficient. Finally some of the learnings of this week are a better understanding of rails, having someone who knows the language and tells you what is wrong and if there is a better way to do something, is something that really helps to have a better understanding and get some tricks. 

Also that not always that are bugs on an app and you are pretty sure that the code works correctly find another explanation for the problem (as the connections with the provider of charges on cards, or the command being run twice).Trying to improve the efficiency of code that has some years needs that the programmer knows the code in a deep way.

Week March 17 - 21

For this week I worked from the client side, we are in Chicago. The purpose of this week  was to show to the client the work that has been done, get more information that helps us do in a better way our work and continue with the order processing topic.

The week started with a shortly meeting with the client, where we met for the first time. That  gave me background to be kind of prepared to the next day. So, for the real meeting, we did a presentation about what is done, what is missing, a little retrospective and got some information.

I showed to the client how a part of the administration side of the application works, and solved some doubts that came after the demonstration. Moreover after talking about the way  in which orders are going to be managed we got a kind of agreement. We propose to the client to manage their preorders with the feature that spree offers, that is a backorderable order, and we will finish the customization of this to give them what they want by adding a field on the product administration page, that says when the product becomes available, and automatically, change that pre-order status and add stock to the product.

For this week are not too many learnings on the technical side, instead of that we got a rich learning  of the client side. Not all the clients are the same, so as a developer I need to figure out the best way to show and say things. Images and diagrams are a helpful tool. We don't need to compromise to everything, as a professional, we need to know when to say no. Sometimes we need to going slowly on the project to make the client confortable, press the client make things not progress.

Getting real with the site (March 10th to 14th)

Another week has passed and after being just working on migrations, things are starting to look as the prototype showed in the firsts meetings. So, for this week I worked on some migrations and making part of the design alive, I'm getting more excited every time with the add-ons on the design.

My week started with the research of how to make the download of the albumes that the client was going to keep as products on the new site. Data transfer is  a really hard process and doing it manually makes it worse. It is as a result of the problem about how to get the digital content that the client is going to keep, that we found a way to do it automatically with an script that runs on a windows operative system, that downloads all the digital content needed. In this way, the script only needs to be generated and run once and it will download the mp3s.

On the other hand also, I started a research about the order processing on the e-commerce tool that we are using. With this research I found that :

1- We are going to be able to charge the user immediately after a purchase, in this way we are going achieve one of the points that they highlight on this topic.

2- We will need to develop an extension of the e-commerce tool, because it does not allow to generate csv file of orders, and the client needs to be able to generate those files to pass them to the invoice system.

3- The e-commerce-tool is not able to manage pre-orders.

After that little research I started coding the functionality to be able to export the orders on a csv file. The outcome of this is good, right now through a button an administrator can get a file with the data that an order has. Now, what is next, is to wait for which is the data  needed for the invoice system and to be able to apply some search criteria to filter orders.

Also, we worked with the designer changing the main page of the site, the site is starting to seem more real.A lot of things happened this week, and hopefully we are going in the right way.

14th Week

 This week on Thrill Jockey I worked doing migrations of products again, that happened because the client sent a list of labels that are not going to be distributed anymore. So the first thing we worked was to redefine the task on ruby on rails, basically the task takes a csv file, previously built, that csv file is red and through a library a hash is created. In that way, we create a cycle that takes each element of the hash, goes and inserts it in the database.

Here something was not really good, we found out that when reading the files generated for each product sometimes it presents errors running the tasks because 2 things had happened:

1. There is a missing/one more space between the name of the file, so when the task runs it fails when needs to run the that file or,

2. There are new characters that we had not seen before.

After we left that running we review with our tech lead the next stories that we are going to develop.  Right now the design is going to take part of the work that is coming, which is great because we will be able to show to the client something more real, more similar to what we showed her at the beginning. It is not going to be anymore just functionality, which in most of the demos was really difficult to get the stories approved because in the majority of the cases we needed to spend a lot of time explaining that what we did is not including the design that is different.

For example, something that happened this week that in fact turns me kind of mad and stressed was that we show something that was agreed the last week, that was a separation between the products that are owned by Thrill Jockey and the ones that are just distributed by them. So we did the separation, and everything was there but the client said that it did not look as she expected. We tried to explain her that the things that were missing are part of the design; at the end we could not approve that “functionality” because of that (we are still trying to make her understand that migration, design and functionality are different things.)

As I explained we had demo, so I needed to upload the new app to the development server, this step is now really easy, after start my internship as part of my tasks I’ve learned to put rails and php apps in the server and set them to be accessible from the web.

Also I had to write a document to Thrill Jockey, because some of the customer data that we had to migrate the last week gave problems so they asked us to send a list of the users that we could not migrate for them to review it and take a decision.  After I finished that document I started to read and research about the new functionality that was on the backlog, which is a research about the order processing.

I started to search about the payment gateways supported by spree, and also the one that is used by Thrill Jockey, fortunately spree seems to support the same gateways. I also spent time searching extensions to export orders into csv files. Unfortunately none of the ones found were compatible with the version of spree that we are using, so after the Tuesday’s demo, I’ll probably start implementing that functionality.

Something really good that I found was that, before when we started using spree to see how it works we were worried because the process of charging the amount of money for the products bought was manually, but this week when I was doing that researching I found that it can be doing without the intervention of an administrator. Basically what I needed to do was to change a line of configuration to make that process automatic.

I made a test after changing that configuration, using the default gateway and it was really cool to see how the state of the payment in the admin part was done, without any intervention. Now what I need to continue with this functionality is to get test accounts for the payment gateways that they need to have in the new site and prove them that everything works as they want.

On that functionality we will need to implement the automatic creation of the zip files after purchase digital products, and make them available in the record crate of each user. On the other hand, we will need to make a separation between the orders and preorders, and the ability to export orders into csv files.

For the next week, we will be working into uploading the digital content to the server, because now we think that will able to have everything in the development server. In fact after running the new scripts filtering the list that the client said the product list was reduced to the half of what they had at the beginning, which shows the amount of garbage that they have in their database.

When we finish the migration of that part I learnt something really important, never let data from your tests into the database, or at least use data that represents what you are testing, do not put just letters, make the data that you are putting as a test have some meaning that could help the next person that will check your database.

Then I worked on Eventwax project, for this week I did a redesign of the messages section, so I worked with saas and rails. This was an easy task, I just needed to change the message that was displayed and make it look as the client asked.

Also I help my coworker with her story that took a lot of time, because we needed to generate a barcode and qr codes for the events tickets, moreover we needed to change the template used to send the emails of attendees. When we finish that story I went to a code review with the tech lead of this project.

During the review, we did some refactoring, and we talk about why we did things in the way we did it. Also I learned some new tips about github, and was a really helpful code review.

13th Week

Thrill Jockey Project(Internship)

Stories:

1. Customer data

As part of this story I was in charge to write the parser for the users and the record crate that was a simple ruby program that takes a csv file and builds a new csv file with the data that the task on the rails application needs to run. So after finish that parser and generate the scripts that we were going to use, we enter into the part of the users authentication, because we needed to modify it to tell the user that it needs to reset the password if its his/her first time on the new site. I worked changing the code of the spree_auth_devise extension to make a new validation when a user tries to sign in into the site. The easiest way to do it was to take advantage of the column that the users table of the database has, which maintains a counter  of how many times a user has logged in. The validation I made was to ask that if that counter is 0 to ask the user to put his email, and we send one with instructions of how to get back its account working. The email contains a link which redirect to a page that let you reset your password. Also as part of this story I worked with cookies, that was the way in which we think that will be the best way to manage the session in the php part of the app. At the end we can say that the functionality was achieved, the thing that is making us not approve that story with the client  is that the migration is taking a long time, there is a lot of data that is not consistent and there are almost 30 000 users.

2. Thrill Jockey/ Distributed Releases

This second story was about to make distinction between the products that are of Thrill Jockey and the ones that are just distributed by them. So we needed to create two actions on the products controller. Also we create the views for that, and the thing that took more time until now was the definition of the route, because as we defined in the beginning it was making us have troubles with the paginator element, but after we got some help of a coworker, we were able to fix that with him. In fact almost the whole story was made in half day, what we are missing about it is to put the query for the distributed releases.

At the end of this week on this project I can say that it was not what I expected because I wanted to approve both stories. So fortunately on Tuesday we are going to approve 16 points.

What did I learn?

Well basically I put in practise, because I've red about it and made examples but not in something that is real:
- define routes, 
- add actions to a controller, 
- add columns to a  database table, 
- add models to an extistent app,
- how to modify the content of a spree extension,
- make queries using active record syntax,
- use cookies to manage sessions between applications in different languages,
- refresh php knowledge.

How to get better?

1. First of all, one of the things that took a lot of time was the migration, so it was in part becasue we did not know about rollbacks on rails, so we are going to research about it and put it on practise for the next migration, and reduce a little bit the time that it takes to run all the tasks.
2. The second thing is that I need to keep the repos cleaner, make commits more frequently.
3. And the third thing that I could improve is not to spend a lot of time searching when I'm in trouble with something, it is better to ask, if its taking a lot of time.
4. Keep using free time to learn more about rails.
5.Testing new code, learn how to make tests with  rspec-rails.

Eventwax Project(Extra)

This week on this project I just worked on Friday, and also that day I was verifying that everything that we had on the other project was right, so I was not focused on it completely. But the good thing is that I fixed a bug and finish a story as part of my day. Also I was in a code review of what my friend and I have done the past two weeks.  I learnt that work with time zones could be a really headache or at least is too difficult for me  J. But on this project every time I feel more confident about what I’m doing. Also the good thing with this is that I’m learning the good news that have been introduced into new versions of rails and ruby, because this uses ruby enterprise edition 1.8 and rails 2.3  while in the other project we are working with rails 4 and ruby 2.