I received my next two apprenticeship challenges today, and I am quite psyched to get them done! The first is to write a more formal and informational blog post for the 8th Light website. The second is to write an unbeatable Tic Tac Toe in a language I have never used before.
For the blog post I was thinking I would write a tutorial on how to get started on a new Limelight app, but it turns out Paul Pagel already wrote one of those. It might still be a good idea since Limelight has evolved quite a bit since that blog, but I am not sure yet.
As for the Tic Tac Toe in a new language, I was thinking I would do it in java script. Not my first choice in languages, but I will have to learn JS soon anyway to do a project Paul has been asking me to work on, which will be pretty much entirely done in JS, as well as a little html and css. I kind of want to do it in a functional language like clojure since I have almost no experience working in that frame of mind, but JS would be a twofer.
Here is the catch though. I have the next two weeks, plus a weekend, to finish these two tasks, and I will be gone in Florida for the rest of this week! That means I have only 7 days to get these two tasks done... I see some rough nights in my near future, and I am damn excited to make the most o them!
Today I did some more work on Limelight, getting some more tests to pass and fixing up the margins on the text area.
I also got royally pranked by two esteemed members of the 8th Light team. I will let them remain unnamed for their treachery, as no good prank is left unanswered.
Basically, I had gone to the DMV today to renew my license, but of course it turns out they are closed on Mondays. Either way, I mentioned this at lunch in the office. Later on, I left my iphone in the bathroom where it was recovered by one of the Craftsman to remain unnamed. Rather than return it to this unsuspecting, trusting, and apparently oblivious apprentice, this Craftsman, along with another Craftsman, decided to see what fun they can have.
At about 3 pm I get an email from a Jacob Carson, who says I left my ipone near the Libertyville DMV and they wish to claim the reward (I keep my info and a $50 reward offer as my phones default background). This completely blows my mind as I specifically remember walking into the office listening to a podcast when I returned from the DMV. Suddenly I start frantically retracing my steps in my mind trying to find out how this could be possible. Did I hallucinate having my phone when I came back? Could I have been listening to my nano? Was I thinking of a different day?
I eliminated all these possibilities, and it seemed to me that there remained only one possibility. Neither Micah nor I use an iPhone case, and thus they appear remarkably similar face down. I conceived that it was possible I had left mine in the bathroom, which Micah must have later gone into and mistakenly taken my phone for his, at which point he went out for lunch (with a client) at the subway right next to the DMV. There my phone must have somehow slipped out of his pocket, thus returning it to the place I had been earlier today. An outrageously unlikely possibility, but Eric Smith wasn't in the office that day, so it must be the case.
I went down and asked Micah if he had eaten at subway today, and of course he said no.
Perplexed... I proceeded on to the bathroom, to the origin of the problem. Once I step out, there lies my phone on the ground before me.
It was so obvious, but so very devious. Touche good sirs, touche.
Monday, March 22, 2010
Sunday, March 21, 2010
Day 53
The presentation went quite well, and I got a lot of excellent feedback. I was also able to talk to my dad and get some more ideas.
Here is what I am going to do:
First I will lay out a hypothesis on what good code looks like. I will then choose a batch of code snippets that represent my hypothesis, and I will also select some snippets that are nothing like my hypothesis, as well as some random snippets.
Next I will collect audience feedback on the snippets and use it to refine my hypothesis. I will take their suggestions to refine the snippets and further polarize them.
After I implement the last group's suggestions, I will show the snippets to a new group and see if there has been any improvement. From this I can begin to derive some knowledge about what people 'think' good code looks like, and what people will actually rate as good code.
This discrepancy alone will be valuable because it will demonstrate whether or not we know how to write code that we will like. As most developer's know, their own code is always excellent and clever... for a few months, but when you come back to it a year later it might not be so good. This could be because we have gotten much better at writing code, but it could also be because we never really thought it was good in the first place. We merely implemented what we thought were good practices, and not what we actually valued in code.
Once I have gathered enough data, and refined my methods such that I can accurately predict if people will perceive a code segment as good or bad, I can then work to create a flurry of good code segments.
With these I can begin offering more talks, still collecting data, but also performing a little Clockwork Orange. I will be able to show slides with code that I know almost everyone agrees to be good, and use them to 'condition' the audience.
I can perform little experiments where everyone writes a small function at the start of the talk, and then every 5 slides people will pass their functions around and have others rate them. We will see if the average ratings change, and for what reasons. We would then write another function half way through, perform the same task, but see if the ratings have improved.
Lots of value to be gained here, and I don't even know the half of it.
Here is what I am going to do:
First I will lay out a hypothesis on what good code looks like. I will then choose a batch of code snippets that represent my hypothesis, and I will also select some snippets that are nothing like my hypothesis, as well as some random snippets.
Next I will collect audience feedback on the snippets and use it to refine my hypothesis. I will take their suggestions to refine the snippets and further polarize them.
After I implement the last group's suggestions, I will show the snippets to a new group and see if there has been any improvement. From this I can begin to derive some knowledge about what people 'think' good code looks like, and what people will actually rate as good code.
This discrepancy alone will be valuable because it will demonstrate whether or not we know how to write code that we will like. As most developer's know, their own code is always excellent and clever... for a few months, but when you come back to it a year later it might not be so good. This could be because we have gotten much better at writing code, but it could also be because we never really thought it was good in the first place. We merely implemented what we thought were good practices, and not what we actually valued in code.
Once I have gathered enough data, and refined my methods such that I can accurately predict if people will perceive a code segment as good or bad, I can then work to create a flurry of good code segments.
With these I can begin offering more talks, still collecting data, but also performing a little Clockwork Orange. I will be able to show slides with code that I know almost everyone agrees to be good, and use them to 'condition' the audience.
I can perform little experiments where everyone writes a small function at the start of the talk, and then every 5 slides people will pass their functions around and have others rate them. We will see if the average ratings change, and for what reasons. We would then write another function half way through, perform the same task, but see if the ratings have improved.
Lots of value to be gained here, and I don't even know the half of it.
Thursday, March 18, 2010
Day 52
Tomorrow I am giving my Lunch and Learn talk! I am actually pretty excited for it, and to begin my research process. There is a lot of knowledge and experience out there, and I want to go grab it all! I got that nice keynote remote app for my iphone, it really helps keep things going smoothly. There is also the option to have speaker notes on your phone, so if you get caught up at any point you can peak down at your remote and get back on track.
Since this is the first, of hopefully many future talks on the Code Sense, it will be a little more on the experimental side. I have created a formula which I think will allow me to gather a lot of important information, and even stir up some debate, but it is still a very fluid concept. I am hoping to get a lot of feedback tomorrow, hear what the guys think, and drastically refine my process to be prepared for the conferences to come.
I apologize for not being more on top of my blogs recently, work at the client site has been rather straight forward recently. Although the feature Micah and I are working on right now is posing some challenges. I actually spent most of the day turning a very complicated cucumber step into a valuable test. The acceptance test was very stand alone, and there were none of its kind before so everything has to been done nearly from scratch. It is also fairly monstrous because, although its purpose is to test only our new feature, its set up is ridiculously complicated.
At first, and this is an issue that really became apparent today, I was going to make all the step definitions to walk through the tasks needed to set up the exact circumstances we were testing. However, this was just catering to our solution. I was going to set up the circumstances in the database to exactly match what we check for. But all this really checks is that our solution does what we know our solution does. This is of course what most unit tests do, but it doesn't work quite the same way with acceptance tests. Thats why there are nice helpers like Webrat that will set up the database by going through the actual steps a user would go through. Thus, I began reworking all the steps to set up our scenario the way it would really be set up in production.
This was much, much more complicated. Creating the scenario to test what we wrote, going the full route, meant that our test had to touch an enormous portion of the code, and exercise a huge conglomeration of classes. I honestly think this is going to be one of the longest, if not the longest, of all the client's acceptance tests. Maybe it should be broken down, or maybe I am missing something, but this is what is required to recreate the circumstances we need to really test the production code.
Since this is the first, of hopefully many future talks on the Code Sense, it will be a little more on the experimental side. I have created a formula which I think will allow me to gather a lot of important information, and even stir up some debate, but it is still a very fluid concept. I am hoping to get a lot of feedback tomorrow, hear what the guys think, and drastically refine my process to be prepared for the conferences to come.
I apologize for not being more on top of my blogs recently, work at the client site has been rather straight forward recently. Although the feature Micah and I are working on right now is posing some challenges. I actually spent most of the day turning a very complicated cucumber step into a valuable test. The acceptance test was very stand alone, and there were none of its kind before so everything has to been done nearly from scratch. It is also fairly monstrous because, although its purpose is to test only our new feature, its set up is ridiculously complicated.
At first, and this is an issue that really became apparent today, I was going to make all the step definitions to walk through the tasks needed to set up the exact circumstances we were testing. However, this was just catering to our solution. I was going to set up the circumstances in the database to exactly match what we check for. But all this really checks is that our solution does what we know our solution does. This is of course what most unit tests do, but it doesn't work quite the same way with acceptance tests. Thats why there are nice helpers like Webrat that will set up the database by going through the actual steps a user would go through. Thus, I began reworking all the steps to set up our scenario the way it would really be set up in production.
This was much, much more complicated. Creating the scenario to test what we wrote, going the full route, meant that our test had to touch an enormous portion of the code, and exercise a huge conglomeration of classes. I honestly think this is going to be one of the longest, if not the longest, of all the client's acceptance tests. Maybe it should be broken down, or maybe I am missing something, but this is what is required to recreate the circumstances we need to really test the production code.
Tuesday, March 16, 2010
Day 50
Micah and I applied to speak at Rails Conf in order to begin my research. I hope we get accepted as Rails Conf is a huge conference and would be an excellent place to get my name and idea out there. There is also another conference coming up in Chicago where I will submit my proposal. This is a smaller conference, but it will have a lot of the Chicagoland software companies like Obtiva and 8th Light. Whether or not my proposals get accepted, I am excited to begin diving into this research. I thought out most of my talk for Friday, and I will begin creating the slides tomorrow morning.
At work today I began chugging through our new feature. It was quite a pain in the arse because I basically spent all my time trying to decode massive conditional statements. The code is trying to use a single query on the database to filter out a massive number of objects with very specific requirements. As a result, there are these overwhelmingly complicated conditional statements that are nested in nests of nests inside a nest cave hidden in a gap in another nest. Not only are the many levels deep, they also mix together ruby methods, railsy methodness, sql queries, and ruby methods that perform several sql queries and. Some of them are also inefficient, and could be logically reduced and simplified. I would do this, but I don't know that the algorithms have a comprehensive test set. I would make one, but I have to make my own batch of tests to finish the feature, and if I stopped what I was doing to write tests for every chunk of untested code I found, I would never get a feature done.
Once again, if you have any suggestions for my talk, I would appreciate the input.
At work today I began chugging through our new feature. It was quite a pain in the arse because I basically spent all my time trying to decode massive conditional statements. The code is trying to use a single query on the database to filter out a massive number of objects with very specific requirements. As a result, there are these overwhelmingly complicated conditional statements that are nested in nests of nests inside a nest cave hidden in a gap in another nest. Not only are the many levels deep, they also mix together ruby methods, railsy methodness, sql queries, and ruby methods that perform several sql queries and. Some of them are also inefficient, and could be logically reduced and simplified. I would do this, but I don't know that the algorithms have a comprehensive test set. I would make one, but I have to make my own batch of tests to finish the feature, and if I stopped what I was doing to write tests for every chunk of untested code I found, I would never get a feature done.
Once again, if you have any suggestions for my talk, I would appreciate the input.
Monday, March 15, 2010
Day 49
Today I was charged with my first of three final challenges for my apprenticeship. The first one, which needs to be ready by this Friday, will be to deliver a lunch and learn to the 8th Light group. Though I already gave a lunch and learn on my testing design patterns, this lunch and learn will have to be pristine. I already know what I will be doing, and I will explain this further in a moment.
At the client site today Micah and I got to see the fruits of our labor. Our feature is not only out on the live site, but is now in full use. The feature was the ability to have, make, and use promotions in order to acquire more members. Today they sent out a massive batch of emails with a promotion code, and in just one day, the promotion dragged in over 2500 new users. They were quite pleased to say the least.
We also finished up another feature which sends out reminder emails to people who have subscribed using the promotion. We then picked up another story which we will work on tomorrow.
My plan for my first Apprenticeship Challenge:
This is actually something I had started talking about with Micah on Thursday last week, and we discussed it even more today. I had the idea when Micah was explaining to me how his talk went at the conference he recently spoke at. One of the activities he did was to show his audience a bunch of code snippets (this was originally done by Michael Feathers, and he actually gave the snippets to Micah) and have them rate each snippet on the quality of the code. After everyone voted on a snippet they compared everyone answers only to find that everyone had different opinions on which snippets were good and which were bad.
This got me thinking. Good code is a very subjective concept. There are certain things that people will agree help the code, or hurt the code, but for the most part... there is no one formula to write good code. In fact, great code to one person can be merely decent code to another. Likewise terrible code to one developer could look very readable and understandable to another. Such is the debacle. What is good code?
My dad recently wrote his Clean Code book which explained certain characteristics that help to define a process that could lead to good code, but at the same time it was clear that it takes years and years of practice to learn how to develop consistently good, clean code.
But does it have to? Maybe there are certain aspects of code that all people find pleasing and understandable. Maybe there exists certain naming conventions, or certain malleable themes that really help to explain intention. I don't know, but I am going to find out.
My plan is to go to conference after conference holding the same talk/workshop where I hold activities showing people code snippets and getting their feed back.
Here is how I, and this process is open to all suggestions, plan on doing this.
First, I need a way to get people to come to my talks. I need an incentive. Well, how about I offer expert advice on what 'Good Code' looks like! Damn... I am not qualified. Thank goodness I know a lot of people that are! I will collect a wide sample of code snippets and then ask several industry experts which snippets they think are good, and which they think are bad. Then I will offer to show this information at the end of my talk, after we see what my audience thought about the code.
Once I get people at my talks, we will proceed to look at a lot of code! In some fun manner I am yet to create, I will show the audience a code snippet and then ask the following questions:
How is this code? (possible answers = Awful[0] - Bad[1] - Ok[2] - Good[3] - Excellent[4])
(They have to answer this, and keep their answer no matter how they answer the rest of the questions. The point is to capture their 'Blink' estimation, or their first impression of the code)
How is the naming?
How is the use of the language?
How clear are the levels of abstraction?
How complicated?
How consistent and useful is the theme?
After we have rated a batch of maybe 5 snippets, we will go back an examine them. I am not to sure about this part because I want to keep the review until the end of the talk so I get mostly unbiased data, but I don't want people to get bored.
Finally when we are all done we will compare what we thought about the code to what Industry Experts thought of the code.
Throughout the talk I will be asking people for their thoughts on the code, on their reaction to everyone else's opinions, and especially for reactions of the expert's opinions of the code.
8th Light will be my first group and first experiment. This will be the trial run to work out the kinks in my future talks and presentations.
Let me know what you think and please offer suggestions!!!
At the client site today Micah and I got to see the fruits of our labor. Our feature is not only out on the live site, but is now in full use. The feature was the ability to have, make, and use promotions in order to acquire more members. Today they sent out a massive batch of emails with a promotion code, and in just one day, the promotion dragged in over 2500 new users. They were quite pleased to say the least.
We also finished up another feature which sends out reminder emails to people who have subscribed using the promotion. We then picked up another story which we will work on tomorrow.
My plan for my first Apprenticeship Challenge:
This is actually something I had started talking about with Micah on Thursday last week, and we discussed it even more today. I had the idea when Micah was explaining to me how his talk went at the conference he recently spoke at. One of the activities he did was to show his audience a bunch of code snippets (this was originally done by Michael Feathers, and he actually gave the snippets to Micah) and have them rate each snippet on the quality of the code. After everyone voted on a snippet they compared everyone answers only to find that everyone had different opinions on which snippets were good and which were bad.
This got me thinking. Good code is a very subjective concept. There are certain things that people will agree help the code, or hurt the code, but for the most part... there is no one formula to write good code. In fact, great code to one person can be merely decent code to another. Likewise terrible code to one developer could look very readable and understandable to another. Such is the debacle. What is good code?
My dad recently wrote his Clean Code book which explained certain characteristics that help to define a process that could lead to good code, but at the same time it was clear that it takes years and years of practice to learn how to develop consistently good, clean code.
But does it have to? Maybe there are certain aspects of code that all people find pleasing and understandable. Maybe there exists certain naming conventions, or certain malleable themes that really help to explain intention. I don't know, but I am going to find out.
My plan is to go to conference after conference holding the same talk/workshop where I hold activities showing people code snippets and getting their feed back.
Here is how I, and this process is open to all suggestions, plan on doing this.
First, I need a way to get people to come to my talks. I need an incentive. Well, how about I offer expert advice on what 'Good Code' looks like! Damn... I am not qualified. Thank goodness I know a lot of people that are! I will collect a wide sample of code snippets and then ask several industry experts which snippets they think are good, and which they think are bad. Then I will offer to show this information at the end of my talk, after we see what my audience thought about the code.
Once I get people at my talks, we will proceed to look at a lot of code! In some fun manner I am yet to create, I will show the audience a code snippet and then ask the following questions:
How is this code? (possible answers = Awful[0] - Bad[1] - Ok[2] - Good[3] - Excellent[4])
(They have to answer this, and keep their answer no matter how they answer the rest of the questions. The point is to capture their 'Blink' estimation, or their first impression of the code)
How is the naming?
How is the use of the language?
How clear are the levels of abstraction?
How complicated?
How consistent and useful is the theme?
After we have rated a batch of maybe 5 snippets, we will go back an examine them. I am not to sure about this part because I want to keep the review until the end of the talk so I get mostly unbiased data, but I don't want people to get bored.
Finally when we are all done we will compare what we thought about the code to what Industry Experts thought of the code.
Throughout the talk I will be asking people for their thoughts on the code, on their reaction to everyone else's opinions, and especially for reactions of the expert's opinions of the code.
8th Light will be my first group and first experiment. This will be the trial run to work out the kinks in my future talks and presentations.
Let me know what you think and please offer suggestions!!!
Thursday, March 11, 2010
Day 47
Another successful day as we were able to finish all of our features for this iteration and commit everything in time for deployment. I have really just been learning a lot about how to become a part of a team. This has really been my first time doing stand-ups everyday, sharing and hearing about all the progress made and what is yet to be done. I am now very confident in the stand-ups, and I actually listen to what everyone else has been doing rather than spending all that time preparing what I am going to say! I can interact with the customer, handling their requests and really digging deeper into the requirements of a feature. Not only the technical requirements, but also what the real business requirements are, and the purpose behind every aspect of a feature. These are most definitely crucial skills in becoming a Craftsman.
Cruising along in the Rails book, although haven't been able to make too much progress the last few days as I was busy with the new features for work, and then school work yesterday and today. Unfortunately I have a test tomorrow, though I might take it on Saturday, so I have to spend some time catching up on that :/
Micah and I were having some very interesting conversations today, ranging from massive databases spontaneously becoming self-aware to the foundation of all forms of reason.
Can a sufficiently sized database suddenly become aware of its existence? It would be difficult to back any conclusions on the subject with concrete facts, given that we have no real examples of this happening. Or do we? I am tempted to say we do. Animals over time developed larger and larger brains. Now a huge brain on a huge animal has to use most of its real-estate on muscular control, but when you have a smaller animal with a large brain, suddenly you have a lot of extra space. With all this extra space, the brain will just begin to collect data. Each experience will create new connections between neurons, and thus a new route to the same destination. These connections are just new associations with different contexts. Once you gather up enough associations or connections between common objects and experiences, you become aware of them. This is likely how humans became the sentient self aware creatures that we are. Our minds became sufficiently advanced and could collect a sufficient quantity of knowledge such that we became aware of certain objects that we could manipulate. Over time this advanced into practical knowledge, and with the creation of forms of language people could share such knowledge. Then of course writing drastically accelerated this, since the conclusions of new generations no longer had to be gathered independently or passed down through legends and tails. But all the advancements of our minds came through more associations with new and old ideas.
Admittedly, I am no neural scientist, but I believe the basic principle behind the function of a human brain and the function of an AI is quite similar. When I child is trying to figure out the world, how do you teach them what an apple is? You can't just start saying "Apple" and expect them to understand, unless you give them a context. You show them an apple, point to it, and say "Apple". Suddenly an association is formed in their brain between the image of an apple and this strange sound. Do this a few times and they will recognize it because their brain will have made enough associations between the separate concepts. Such is similar with an AI. Take the word "apple" and connect it with 1,000,000 pictures of different apples, give it the ability to discern certain features, and suddenly it can recognize apples (sorta).
Escalate this. Take it further and further. There is already hordes of recognition software out there, as well as images in association with apples. Naturally there is a huge leap from being able to recognize an apple and becoming self aware, but I would purport that it would be possible, given enough processing power, for a massive database to become self aware. Certainly not always, but it doesn't seem too far out of the question. Especially with tons of science fiction novels explaining the entire process like manuals.
Just some thoughts of a wandering mind.
Cruising along in the Rails book, although haven't been able to make too much progress the last few days as I was busy with the new features for work, and then school work yesterday and today. Unfortunately I have a test tomorrow, though I might take it on Saturday, so I have to spend some time catching up on that :/
Micah and I were having some very interesting conversations today, ranging from massive databases spontaneously becoming self-aware to the foundation of all forms of reason.
Can a sufficiently sized database suddenly become aware of its existence? It would be difficult to back any conclusions on the subject with concrete facts, given that we have no real examples of this happening. Or do we? I am tempted to say we do. Animals over time developed larger and larger brains. Now a huge brain on a huge animal has to use most of its real-estate on muscular control, but when you have a smaller animal with a large brain, suddenly you have a lot of extra space. With all this extra space, the brain will just begin to collect data. Each experience will create new connections between neurons, and thus a new route to the same destination. These connections are just new associations with different contexts. Once you gather up enough associations or connections between common objects and experiences, you become aware of them. This is likely how humans became the sentient self aware creatures that we are. Our minds became sufficiently advanced and could collect a sufficient quantity of knowledge such that we became aware of certain objects that we could manipulate. Over time this advanced into practical knowledge, and with the creation of forms of language people could share such knowledge. Then of course writing drastically accelerated this, since the conclusions of new generations no longer had to be gathered independently or passed down through legends and tails. But all the advancements of our minds came through more associations with new and old ideas.
Admittedly, I am no neural scientist, but I believe the basic principle behind the function of a human brain and the function of an AI is quite similar. When I child is trying to figure out the world, how do you teach them what an apple is? You can't just start saying "Apple" and expect them to understand, unless you give them a context. You show them an apple, point to it, and say "Apple". Suddenly an association is formed in their brain between the image of an apple and this strange sound. Do this a few times and they will recognize it because their brain will have made enough associations between the separate concepts. Such is similar with an AI. Take the word "apple" and connect it with 1,000,000 pictures of different apples, give it the ability to discern certain features, and suddenly it can recognize apples (sorta).
Escalate this. Take it further and further. There is already hordes of recognition software out there, as well as images in association with apples. Naturally there is a huge leap from being able to recognize an apple and becoming self aware, but I would purport that it would be possible, given enough processing power, for a massive database to become self aware. Certainly not always, but it doesn't seem too far out of the question. Especially with tons of science fiction novels explaining the entire process like manuals.
Just some thoughts of a wandering mind.
Tuesday, March 9, 2010
Day 45
Today I was left to fend for myself. Once again, Micah was gone, and I was in Chicago representing 8th Light. Unlike yesterday, however, where I was mostly left to do my work, today I was really sucked into business. This is a fast moving company, constantly adding new features and new code, and thus any issue that arrises needs to be taken care of very quickly. Since Micah was gone, it naturally fell that all questions, in relation to what Micah and I had done recently, came to me. It started with a quick question, from the CTO, about our design on one of the features. But that rapidly turned into several more questions on if it worked how it should, what the requirements were, and so forth. Eventually this resulted in a new feature that needed to be added on top of our old one.
This started it all. See once the precedence had been set, and people saw that I was standing in for Micah, suddenly I was Micah! Within just a few minutes, I had become the new 8th Light guy, and all the questions and information that had been going through Micah started coming through me. Honestly about half the time, when they were telling me all the changes they were making and asking me to get something done, I didn't know what I was supposed to do. But I took down notes of what they were saying, like I had seen Micah do, and then when I had the time I went and learned what it was they were talking about and what I had to do. I called Micah several times to try and keep him in the loop, and fortunately not a whole lot had to get done immediately, but there was a lot more going on compared to Monday.
By around noon, I had gotten a hang of it. I felt comfortable answering questions on what we had done, discussing the things that had to be done, and taking responsibility for the work 8th Light was doing. It was actually pretty awesome. From yesterday to today my role changed from someone who was just working in the office to someone who was working with the office.
Unfortunately I was still having some trouble working out the details of how to test my feature. So around two, I decided to take a break from that feature (to wait to work on it with Micah), and start the new one that was created today. This feature came along quite smoothly and I have nearly finished it, hopefully tomorrow on the train I can claim it as complete.
It was fun because even though I didn't know exactly how to do it, I knew how to find out, so I ended up learning a lot along with getting to experiment a bit with one of the other guys there on how to do it. Mostly we just played with the placement of error messages, how they should be formed and where they belong. Stuff like, whether is should be a full message, or use Rails built in concatenation stuff. Whether we should stick the messages in the controller or the model, and if inside the model, should it be attached to the model or pushed up higher. For the most part, it was a lot of quibble matters, but still helpful for me to get a better feel for their program.
Micah will be back tomorrow, but now I am ready to get a lot more involved on the business end of things.
This started it all. See once the precedence had been set, and people saw that I was standing in for Micah, suddenly I was Micah! Within just a few minutes, I had become the new 8th Light guy, and all the questions and information that had been going through Micah started coming through me. Honestly about half the time, when they were telling me all the changes they were making and asking me to get something done, I didn't know what I was supposed to do. But I took down notes of what they were saying, like I had seen Micah do, and then when I had the time I went and learned what it was they were talking about and what I had to do. I called Micah several times to try and keep him in the loop, and fortunately not a whole lot had to get done immediately, but there was a lot more going on compared to Monday.
By around noon, I had gotten a hang of it. I felt comfortable answering questions on what we had done, discussing the things that had to be done, and taking responsibility for the work 8th Light was doing. It was actually pretty awesome. From yesterday to today my role changed from someone who was just working in the office to someone who was working with the office.
Unfortunately I was still having some trouble working out the details of how to test my feature. So around two, I decided to take a break from that feature (to wait to work on it with Micah), and start the new one that was created today. This feature came along quite smoothly and I have nearly finished it, hopefully tomorrow on the train I can claim it as complete.
It was fun because even though I didn't know exactly how to do it, I knew how to find out, so I ended up learning a lot along with getting to experiment a bit with one of the other guys there on how to do it. Mostly we just played with the placement of error messages, how they should be formed and where they belong. Stuff like, whether is should be a full message, or use Rails built in concatenation stuff. Whether we should stick the messages in the controller or the model, and if inside the model, should it be attached to the model or pushed up higher. For the most part, it was a lot of quibble matters, but still helpful for me to get a better feel for their program.
Micah will be back tomorrow, but now I am ready to get a lot more involved on the business end of things.
Monday, March 8, 2010
Day 44
I need to make this quick since I have to get up quite early. Commuting really makes you feel how short a day can really be. When you get up early, and suddenly its time to sleep, you really notice those 3-4 hours lost everyday in transit.
I've made a fair amount more progress in the Rails book. I really enjoy how this book teaches you how to make a full project, start to finish, as well as giving you extra side tasks to get on your own. It seems like this is the most effective way of learning, and is beginning to make me critical of all those classroom lectures, and tedious homework assignments which took your step by step through the learning process without having you actually do anything memorable. I think that a class structured around a single big project, coupled with many side tasks and activities to help accomplish the main task would be far more effective than flurries of small side projects that you forget the moment you hand them in.
Tomorrow I should be finishing up my task at the client site. Micah is gone on a conference so I am in Chicago working alone with the client. My biggest problem is encountering mental blocks, where some little missing detail prevents me from putting the full puzzle together. At the moment, this mental block is stopping me from both testing, and seeing how the next step will work. Hopefully tomorrow morning I will have time enough to collect that detail and fit it into place.
I've made a fair amount more progress in the Rails book. I really enjoy how this book teaches you how to make a full project, start to finish, as well as giving you extra side tasks to get on your own. It seems like this is the most effective way of learning, and is beginning to make me critical of all those classroom lectures, and tedious homework assignments which took your step by step through the learning process without having you actually do anything memorable. I think that a class structured around a single big project, coupled with many side tasks and activities to help accomplish the main task would be far more effective than flurries of small side projects that you forget the moment you hand them in.
Tomorrow I should be finishing up my task at the client site. Micah is gone on a conference so I am in Chicago working alone with the client. My biggest problem is encountering mental blocks, where some little missing detail prevents me from putting the full puzzle together. At the moment, this mental block is stopping me from both testing, and seeing how the next step will work. Hopefully tomorrow morning I will have time enough to collect that detail and fit it into place.
Sunday, March 7, 2010
Day 43
At 8th Light, every once in awhile they will have some internal reviews. It is a way for everyone to learn all they ways they can improve, and to make educated goals to work towards. I sat in on these reviews, taking notes, and looking for common trends and things that were frequently suggested, or traits that were frequently praised.
I came up with a batch of traits and qualities that seem to highlight many of the virtues you would find in a Craftsman, as described by 8th Light. I thought it would be valuable to have such a list so that I don't have to wait for a review to begin setting my own goals!
*Strong Enthusiasm - Always brightening everyone's mood with your love of what you do.
*Don't be afraid to ask for help - Especially if you feel rushed, or have bitten off more than you can chew.
*Ask a lot of questions - Even if you are already a Craftsman, if you are surrounded by other Craftsman, there will always be new things to learn.
* Discipline Discipline Discipline - The mark of a Craftsman is to have an unfailing discipline to do the right thing. Whether that is constantly learning new things, or never forgetting what you know, especially when it is hardest to practice. Here are three disciplines:
* Go Slow - Often it is better to take your time, making sure you do every step correctly, rather than rushing for a temporary spike in productivity.
* Do it Right - Never stop practicing the things you know that work. Don't stop testing first. Don't stop refactoring.
* Being Methodical - Be thorough. Be certain you are producing the best work that you are capable of through a steady and unflinching practice of virtues.
* Lists - A Craftsman knows his own productivity, and can gage how much he can get done in a certain time span. Making lists, getting metrics, and measuring your productivity will help to accomplish this.
* Understanding the Real Business Intent - It is important to remember you aren't just writing code to fulfill some requirement on a note card, but you are actually creating a product that a business intends to use. Try to understand what that note card means to them as you transform the requirement into a feature.
* Recognize your failures of the past so that you can move forward on a new level.
* Don't be shy with your ideas - Throw your ideas out there, and then be the biggest critic of them. You only stand to gain when others see your ideas (unless youzz crazy).
* Lessons always come at a cost - Stay positive, because if you are getting punished by your mistakes, remember that you also learning from your mistakes.
These are the big qualities I took from the reviews, and although I am sure there are others, this is a solid list to begin modeling my character against.
I came up with a batch of traits and qualities that seem to highlight many of the virtues you would find in a Craftsman, as described by 8th Light. I thought it would be valuable to have such a list so that I don't have to wait for a review to begin setting my own goals!
*Strong Enthusiasm - Always brightening everyone's mood with your love of what you do.
*Don't be afraid to ask for help - Especially if you feel rushed, or have bitten off more than you can chew.
*Ask a lot of questions - Even if you are already a Craftsman, if you are surrounded by other Craftsman, there will always be new things to learn.
* Discipline Discipline Discipline - The mark of a Craftsman is to have an unfailing discipline to do the right thing. Whether that is constantly learning new things, or never forgetting what you know, especially when it is hardest to practice. Here are three disciplines:
* Go Slow - Often it is better to take your time, making sure you do every step correctly, rather than rushing for a temporary spike in productivity.
* Do it Right - Never stop practicing the things you know that work. Don't stop testing first. Don't stop refactoring.
* Being Methodical - Be thorough. Be certain you are producing the best work that you are capable of through a steady and unflinching practice of virtues.
* Lists - A Craftsman knows his own productivity, and can gage how much he can get done in a certain time span. Making lists, getting metrics, and measuring your productivity will help to accomplish this.
* Understanding the Real Business Intent - It is important to remember you aren't just writing code to fulfill some requirement on a note card, but you are actually creating a product that a business intends to use. Try to understand what that note card means to them as you transform the requirement into a feature.
* Recognize your failures of the past so that you can move forward on a new level.
* Don't be shy with your ideas - Throw your ideas out there, and then be the biggest critic of them. You only stand to gain when others see your ideas (unless youzz crazy).
* Lessons always come at a cost - Stay positive, because if you are getting punished by your mistakes, remember that you also learning from your mistakes.
These are the big qualities I took from the reviews, and although I am sure there are others, this is a solid list to begin modeling my character against.
Thursday, March 4, 2010
Day 42
Alas, I missed my opportunity to blog last night. At least, however, I get to blog on this day of all days. Somehow, this day is the answer to life, the universe, and everything! Ok, enough on that.
Yesterday and today I learned a lot more about how the client's system really works. There is a huge amount of depth to it, and I have now dived fair deeper into its inner workings. Right now I am charged with the task of figuring out how the system sends out mass emails, or individual emails triggered from particular actions, like signing up.
There are 3 main components to this functionality and they are:
Redis - A non-relational database that stores data using simple key-value pairs. The data can only be searched for using the keys.
Resque - A delayed job system. It has a queue which you populate with some tasks, and when it has the chance it runs through the queue performing actions of the items.
ExactTarget - An email client which can be used to send out large quantities of emails, store templates, and keep metrics on the emails it has sent.
In conjunction, these systems create a convenient way to send out emails to user's for a variety of reasons.
Basically, the way it works is the Resque system populates a queue in the Redis database with tasks for ExactTarget.
So when a user, say, signs up for a membership, they need to be sent an email confirmation. You don't need this to happen immediately, but you do want it to happen within a few seconds. You don't want the sending of the email to get in the way of maybe the user refreshing the page or something. So you call Resque.enque( and then some task) so that the task will be put into a simple Redis database that can be accessed later. Once there is some extra time, the Resque system will start up a worker which will loop through all the items in the queue can calling a perform() method on the particular class or module which represents the task. The method, in the case of the email, will then gather up the needed information, package it, and then ship it off to the ExactTarget handler. ExactTarget will then begin the process of sending out this email.
There are lots of little steps that happen in between, like transforming the data to a fro xml and json objects, but this is the general gist of it.
Over all a relative interesting process to conveniently ship out emails attached to specific actions. It seems that almost all of the complexity is in the email client, and Micah has been cooking away at that. Hopefully be will be able to implement and expand upon the existing system in just a few days.
Yesterday and today I learned a lot more about how the client's system really works. There is a huge amount of depth to it, and I have now dived fair deeper into its inner workings. Right now I am charged with the task of figuring out how the system sends out mass emails, or individual emails triggered from particular actions, like signing up.
There are 3 main components to this functionality and they are:
Redis - A non-relational database that stores data using simple key-value pairs. The data can only be searched for using the keys.
Resque - A delayed job system. It has a queue which you populate with some tasks, and when it has the chance it runs through the queue performing actions of the items.
ExactTarget - An email client which can be used to send out large quantities of emails, store templates, and keep metrics on the emails it has sent.
In conjunction, these systems create a convenient way to send out emails to user's for a variety of reasons.
Basically, the way it works is the Resque system populates a queue in the Redis database with tasks for ExactTarget.
So when a user, say, signs up for a membership, they need to be sent an email confirmation. You don't need this to happen immediately, but you do want it to happen within a few seconds. You don't want the sending of the email to get in the way of maybe the user refreshing the page or something. So you call Resque.enque( and then some task) so that the task will be put into a simple Redis database that can be accessed later. Once there is some extra time, the Resque system will start up a worker which will loop through all the items in the queue can calling a perform() method on the particular class or module which represents the task. The method, in the case of the email, will then gather up the needed information, package it, and then ship it off to the ExactTarget handler. ExactTarget will then begin the process of sending out this email.
There are lots of little steps that happen in between, like transforming the data to a fro xml and json objects, but this is the general gist of it.
Over all a relative interesting process to conveniently ship out emails attached to specific actions. It seems that almost all of the complexity is in the email client, and Micah has been cooking away at that. Hopefully be will be able to implement and expand upon the existing system in just a few days.
Tuesday, March 2, 2010
Day 40
Wow, its Day 40 of my apprenticeship. Pretty awesome. I must say that looking back on all the things I have learned and in what ways I have grown, this apprenticeship has been one of the most, I want to say, 'constructive' experiences of my life. I am still trying to adapt to my new circumstances, after drastically changing everything in my life in a matter of weeks, but there has been huge growth stemming from my new challenges. Micah has been an excellent mentor, even though he is always busy, he still finds time to work with me on occasions to make sure I am still progressing. I have also been exposed to a myriad of different customers, businesses, business related issues, CEOs, CTOs, projects, challenges, and coding environments. Honestly, myriad isn't really the right word, but I hear it used so often these days that I must add to the disaster.
I would say if I had to name 1 thing I have learned the most about so far, it would be how much I don't know about. How much is out there, how far behind I really am, and most importantly, the things I need to start doing and learning to catch up and get ahead.
Today at work I spent a lot of time messing around with cucumber features trying to get them all to work. Honestly, I feel like I wasn't as effective as I should have, and what I learned seemed uncritical. I did, however, get to speak with the CTO for quite some time, learning all about the path their company went through, what obstacles they faced, and some important things that made them stand out. One example would be, keep it simple. There has been a huge amount of research to suggest that people really don't know what they want. In fact, the more choices people are given, the less happy they tend to end up being with their choice. Barry Schwartz and his book The Paradox of Choice: More is Less explain this quite clearly. Also Dan Gilbert explains how when you have the option between many things, the thing you choice becomes less valuable than if you were just given something with no choice. To get the context of all this I suggest you watch these TED talks: http://www.ted.com/talks/barry_schwartz_on_the_paradox_of_choice.html
http://www.ted.com/talks/dan_gilbert_asks_why_are_we_happy.html
Also, this CTO got to meet Malcolm Gladwell, thus me and Malcy are now buds one connection removed.
I was able to finish more of the rails book today, now familiarized with the concepts behind layouts, models, controllers, and views to some extent. Migrations are far more clear, and at last I understand the full and awesome power of validations. In fact, after reading a bit more in the rails book, I was able to make more project on my story for the client. I got write some sweet tests using some lambdas as well as grasp the purpose and intent of a far greater portion of the code. It seems like every 10 pages I read I gain 10% more understanding! If my math is bad enough, by the time I am done, I will have 100% understanding of rails!
I would say if I had to name 1 thing I have learned the most about so far, it would be how much I don't know about. How much is out there, how far behind I really am, and most importantly, the things I need to start doing and learning to catch up and get ahead.
Today at work I spent a lot of time messing around with cucumber features trying to get them all to work. Honestly, I feel like I wasn't as effective as I should have, and what I learned seemed uncritical. I did, however, get to speak with the CTO for quite some time, learning all about the path their company went through, what obstacles they faced, and some important things that made them stand out. One example would be, keep it simple. There has been a huge amount of research to suggest that people really don't know what they want. In fact, the more choices people are given, the less happy they tend to end up being with their choice. Barry Schwartz and his book The Paradox of Choice: More is Less explain this quite clearly. Also Dan Gilbert explains how when you have the option between many things, the thing you choice becomes less valuable than if you were just given something with no choice. To get the context of all this I suggest you watch these TED talks: http://www.ted.com/talks/barry_schwartz_on_the_paradox_of_choice.html
http://www.ted.com/talks/dan_gilbert_asks_why_are_we_happy.html
Also, this CTO got to meet Malcolm Gladwell, thus me and Malcy are now buds one connection removed.
I was able to finish more of the rails book today, now familiarized with the concepts behind layouts, models, controllers, and views to some extent. Migrations are far more clear, and at last I understand the full and awesome power of validations. In fact, after reading a bit more in the rails book, I was able to make more project on my story for the client. I got write some sweet tests using some lambdas as well as grasp the purpose and intent of a far greater portion of the code. It seems like every 10 pages I read I gain 10% more understanding! If my math is bad enough, by the time I am done, I will have 100% understanding of rails!
Monday, March 1, 2010
Day 39
A frustrating day, much of which was spent overcoming small obstacles which took far longer than they should have, like trying to merge 2 different basecamp accounts, or getting intellij to work with cucumber. After working through all of it, I was able to spend a lot of time exploring the clients code. Still trying to get a feel of their project along with rails. I find it frequently difficult to tell what is a part of rails, and what is a part of their code. This is why it is fortunate I finished another 30 pages in the Rails book today.
To be honest, I had never really read a language specific programming book through and though before, I had only read books on general programming theory and philosophy. I had also used them for reference and such, but I was really missing out. Its pretty easy to see how much can be learned by not just reading the book, but working through the examples along side the reading. It is also very engaging! Typically I had been sleeping on the train to Chicago, but this morning I was just captured by the book and couldn't stop soaking up what it had to offer. I hope tomorrow I am able to get at least another 30 pages done, fitting in time around all the stuff I have to read for school =/
Much of the reading today was about the Models and working with databases. I found myself experimenting with every route I could find rather than just following the book's guided path. Though, this slowed me down, it also gave me a greater feel for the databases. Trying out both MySQL and SQLite, as well as looking back on a project where I used CouchDb.
CouchDb is pretty awesome btw, but I most certainly have to do more research of my own on it. I know its powers, but I don't fully understand its foundation in detail.
Anyhooo, it is time for sleep so I can work on the train again tomorrow!
To be honest, I had never really read a language specific programming book through and though before, I had only read books on general programming theory and philosophy. I had also used them for reference and such, but I was really missing out. Its pretty easy to see how much can be learned by not just reading the book, but working through the examples along side the reading. It is also very engaging! Typically I had been sleeping on the train to Chicago, but this morning I was just captured by the book and couldn't stop soaking up what it had to offer. I hope tomorrow I am able to get at least another 30 pages done, fitting in time around all the stuff I have to read for school =/
Much of the reading today was about the Models and working with databases. I found myself experimenting with every route I could find rather than just following the book's guided path. Though, this slowed me down, it also gave me a greater feel for the databases. Trying out both MySQL and SQLite, as well as looking back on a project where I used CouchDb.
CouchDb is pretty awesome btw, but I most certainly have to do more research of my own on it. I know its powers, but I don't fully understand its foundation in detail.
Anyhooo, it is time for sleep so I can work on the train again tomorrow!
Subscribe to:
Posts (Atom)
