I was able to complete my Limelight app for FitNesse, which displays the hierarchy of pages in an agreeable manner. A few issues came up, such as whether I should load all the pages at once (which I tried at first, but it would take about 10 seconds to load!) or only load the current level pages, and then load a page's children when the user expands that page (by clicking on the plus sign which then becomes a minus sign, this is hopefully a familiar structure). For the most part it all went smoothely, and my code is, I believe, 100 % tested (except for my GUI code, which I wasn't sure how to test but Micah says there is a way to do it). I also added a new small little FitNesse feature, that made life easier for my limelight app.
Much of today has been spent working with my dad on refactoring my tests and code for the AddChildResponder for FitNesse. Its funny, when I look at the code and think it looks pretty readable and well abstracted, my dad will see it and say "But oh, look at this, these 3 lines show up here, here and here... Lets extract that into a new method. Ahh, thats better," then low and behold it becomes even more clear what my intentions were when I was writing the code... even if I hadn't known those were my intentions. Its a pretty awesome skill that I hope to acquire in time.
Friday, May 29, 2009
Wednesday, May 27, 2009
Day 4 & 5
So I have been given a project in my mentors absence. I must create a tree structure for the names of all the Fitnesse pages in limelight, such that all the pages will be displayed in an expandable list. I will first need to create a limelight app that can display the list correctly. Then I need to get the names of the pages from Fitnesse, and use my Limelight app to display that list of all the names. Finally I believe I will need to use the names in the list as links that will open a browser to that Fitnesse page. Yesterday I re-familiarized myself with Ruby and Limelight, finally got Rspec to work in text-mate after working for about two hours to get it to work in Intellij, only to find that Intellij has a bug that prevents you from opening project structures in certain cases. I also got a start on the gui aspect of this project. Today I got a large amount of the list and tree node code all done, as well as finished the skeleton of what the Limelight app should look like. Now I must find a way to pull the names from Fitnesse into my app, and then implement the list structure once I have the names. Finally I will need to make those names links.
I also got a few more of the Craftsmanship articles done, and am about 100 pages into Clean Code (its a very dense book, and takes awhile to recognize the important details in the code).
I also got a few more of the Craftsmanship articles done, and am about 100 pages into Clean Code (its a very dense book, and takes awhile to recognize the important details in the code).
Thursday, May 21, 2009
Day 3
Today we got done LightHouse task #23, the add child button for any wiki page. I did the AddChildPageResponder which would handle the command to create a child, passing the correct response to the browser as well as generating a new page with a given name, content, and page attributes. I also made a fairly decent dent in Clean Code! SMALL FUNCTIONS! ok i get it, 1 goal per function. Also got done a few more of the Craftsmanship article, I will add summaries tomorrow. We still need to write acceptance tests for Lighthouse #23 though
Wednesday, May 20, 2009
Day 2
Today we got to work on fitnesse. We solved Lighthouse request #121 where we made scenario libraries add themselves automatically for all slim test pages using the uncle hierarchy. Wrote lots of tests, did almost no debugging :)
Finished at least 5 more Craftsmanship articles, though I am a little uncertain about the meaning behind #22 and #23.
Finished at least 5 more Craftsmanship articles, though I am a little uncertain about the meaning behind #22 and #23.
Tuesday, May 19, 2009
Craftsmanship Article Notes
These are my notes on the craftsmanship articles. If you find any flaws, mistakes, or perhaps something else that should be included in my notes then please inform me because I would like to understand principles in the articles as best I can.
Notes from Craftsman 1-5:
-A function can have only one purpose
-Meaningful names
-Don't get attached to your code, deleting it can help sometimes
-Write the simplest test that will fail, then solve it in the simplest more generalizing manner
Craftsman 6:
race condition: when two threads are running at the same time, and something in one thread must finish before something in the other thread finishes
-When dealing with threads, make a habit of running tests several times, checking for race conditions
Craftsman 7:
Mock Object: an interface in the testing unit that allows you to create a mock user of your code. It helps keep the testing code in the test unit and out of the real code.
Craftsman 8:
Tests are useful even if they don't add to your functionality. They are a form of documentation for your code. They demonstrate to your user, or another craftsman, the purpose and the function of your code.
Craftsman 9:
reentrant: when a function is entered more than once before it exits. This can be done by accessing the function through two separate threads, and ending the first one after the second. Run the tests a few times, the threads may interfere with one another.
Craftsman 10:
Its important to make sure you maintain the way threads are running at all times. When using lists, be sure not to leave an iterator open for long when other threads might by modifying the list.
Read about Design Patterns. Decorator pattern (synchronizedList)
Decorator - An object which defers to the object it inherits from in order to work around a dependency.
Craftsman 11:
The design for your code should be in the tests. Who ever writes the test, dictates the design and manner of your code. Start your program by writing the tests, not the main function. For a well written batch of code, your main really isn't very important and can be written close to the end of design.
Craftsman 12:
It is possible to make stubs for testing. Stubs are the outline of a class or function that do no work, but allow you to make the function calls.
Always be certain to extract duplicated code as soon as you find it.
Make small incremental changes.
Craftsman 13:
Thinking abstractly about code is essential. If you can abstract a group of variables into an object instead, you have generally made the code simpler and easier to change and read.
To "Micah" someone is to find a simpler way (or simpler abstraction) to solve a problem and to make aspects of their code, that they anticipated would be needed, obsolete.
Craftsman 14:
Write purposeful tests. Tests that test functionality that is not a requirement aren't very useful.
Craftsman 15:
Single Responsibility Principle: "A class should have one and only one reason to change. All the functions and variables of that class should work for a single goal. A class should have only one goal."
Craftsman 16:
Template Method pattern: To eliminate duplication, where the duplicated code would be similar but with different parameters you can create an abstract class with different functions to establish the different parameters. You make an abstract method for a higher level class, then extend that class and have the methods in the lower level class define the abstract method.
abstract public class Sorter {
public Sort();
abstract public compare();
}
public class IntegerSorter extends Sorter {
public compare() //and this would define compare for integers
Study those patterns!
Craftsman 17:
Rather than using a chain of if statements, it is often better to use Guard statements. This is where you flip the if from: if (this) {do} else {don't} to: if(!this){return} {do}
Take note of single/entry single/exit
Craftsman 18:
Another good reason for writing tests and code is because its like writing everything twice, and perhaps a typo in one place will be caught because you didn't make the same typo in the other. Known as dual entry bookkeeping
There should be no rushing your work. Always make clean code over a lot of ugly code that works. Lots of ugly code will always slow you down in the long run.
Craftsman 19:
If you write slowly, clearly, and thoughtfully you can end up getting a lot more done than if you rush. You will spend far less time debugging.
Craftsman 20:
Its possible you will get a batch of ideas and want to code them out before you can think of tests for them. Then it is possible the batch of code will do something that looks like it works, but without tests, you might not really understand what is happening. Tests give you a foundation of understanding. Its like measuring out and cutting each piece of wood for a house to exact specifications and knowing for certain that every piece will fit, rather than lining up a bunch of wood and cutting through them all at once with a giant machete and hoping everything will stand the way you pictured it working out in your mind.
Craftsman 21:
A note on deleting directories, it might be a good idea to check for subdirectories and files in those subdirectories before you delete the primary directory.
Make sure your tests clean up after themselves.
Craftsman 22:
A foreshadow to a grave mistake that I believe Alphonse and Avery are making. To add just a bit of functionality that made a wide range of changes to the code all over the place. All these changes were done without writing new tests and as a chain of changes trying to make the last test work without rethinking their strategy. Although I felt uneasy about this, no note of a mistake was mentioned in the following articles... I am uncertain of the intended message.
Craftsman 23:
An example of pair programming, write the test then have your pair make it pass. StarCraft > LandCraft
Craftsman 24:
A sort of interlude to the next section. Also acceptances tests can help organize the structure of your code.
Craftsman 25:
An explanation of acceptance tests, their purpose as the requirements, and the idea that they can be written by the project managers, and the craftsman make them pass.
Craftsman 26:
Introduction to fitnesse. Writing acceptance tests.
Craftsman 27:
Some what deeper explanation of writting acceptance tests, and a Fitnesse.
A reminder of the need for not only unit tests, but acceptance tests as well, and the importance of the tests having the ability to test the code.
Craftsman 28:
Public vs private fields in classes. Much of OOP is centered around encapsulating variables, data, and ideas, and thus it is often appropriate to use getter and setter methods; however, for data structures that are mostly used to transfer data, getters and setters would be a waste and thus public fields are advisable. With objects, you mostly want private variables, with data structures (such as Fitnesse Fixtures) you can have public variables.
Craftsman 29:
Tests aren't a waste of time.
Another common trend that is being displayed, and easily observed in the real world is a stubbornness to do things the way you have always done them. The wise man isn't the smartest, or the one who always knows what to do, but the one whom corrects his mistakes the moment he sees he was wrong.
Craftsman 30:
Hooking up Fitnesse to the application via fixtures.
Craftsman 31:
For acceptance tests you don't do the simplest thing to make it pass, thats for unit tests. For acceptance tests you need to really make them work, and use unit tests to get you to that point. If you are tempted to use a simple method to solve the acceptance tests, chances are you need more unit tests (unless the solution is actually simple of course).
To deal with a database, without specifically writing functions in the database itself, you can use a gateway/interface. This is an object that knows how to handle the data. Push off decisions about the database for as long as possible.
Notes from Craftsman 1-5:
-A function can have only one purpose
-Meaningful names
-Don't get attached to your code, deleting it can help sometimes
-Write the simplest test that will fail, then solve it in the simplest more generalizing manner
Craftsman 6:
race condition: when two threads are running at the same time, and something in one thread must finish before something in the other thread finishes
-When dealing with threads, make a habit of running tests several times, checking for race conditions
Craftsman 7:
Mock Object: an interface in the testing unit that allows you to create a mock user of your code. It helps keep the testing code in the test unit and out of the real code.
Craftsman 8:
Tests are useful even if they don't add to your functionality. They are a form of documentation for your code. They demonstrate to your user, or another craftsman, the purpose and the function of your code.
Craftsman 9:
reentrant: when a function is entered more than once before it exits. This can be done by accessing the function through two separate threads, and ending the first one after the second. Run the tests a few times, the threads may interfere with one another.
Craftsman 10:
Its important to make sure you maintain the way threads are running at all times. When using lists, be sure not to leave an iterator open for long when other threads might by modifying the list.
Read about Design Patterns. Decorator pattern (synchronizedList)
Decorator - An object which defers to the object it inherits from in order to work around a dependency.
Craftsman 11:
The design for your code should be in the tests. Who ever writes the test, dictates the design and manner of your code. Start your program by writing the tests, not the main function. For a well written batch of code, your main really isn't very important and can be written close to the end of design.
Craftsman 12:
It is possible to make stubs for testing. Stubs are the outline of a class or function that do no work, but allow you to make the function calls.
Always be certain to extract duplicated code as soon as you find it.
Make small incremental changes.
Craftsman 13:
Thinking abstractly about code is essential. If you can abstract a group of variables into an object instead, you have generally made the code simpler and easier to change and read.
To "Micah" someone is to find a simpler way (or simpler abstraction) to solve a problem and to make aspects of their code, that they anticipated would be needed, obsolete.
Craftsman 14:
Write purposeful tests. Tests that test functionality that is not a requirement aren't very useful.
Craftsman 15:
Single Responsibility Principle: "A class should have one and only one reason to change. All the functions and variables of that class should work for a single goal. A class should have only one goal."
Craftsman 16:
Template Method pattern: To eliminate duplication, where the duplicated code would be similar but with different parameters you can create an abstract class with different functions to establish the different parameters. You make an abstract method for a higher level class, then extend that class and have the methods in the lower level class define the abstract method.
abstract public class Sorter {
public Sort();
abstract public compare();
}
public class IntegerSorter extends Sorter {
public compare() //and this would define compare for integers
Study those patterns!
Craftsman 17:
Rather than using a chain of if statements, it is often better to use Guard statements. This is where you flip the if from: if (this) {do} else {don't} to: if(!this){return} {do}
Take note of single/entry single/exit
Craftsman 18:
Another good reason for writing tests and code is because its like writing everything twice, and perhaps a typo in one place will be caught because you didn't make the same typo in the other. Known as dual entry bookkeeping
There should be no rushing your work. Always make clean code over a lot of ugly code that works. Lots of ugly code will always slow you down in the long run.
Craftsman 19:
If you write slowly, clearly, and thoughtfully you can end up getting a lot more done than if you rush. You will spend far less time debugging.
Craftsman 20:
Its possible you will get a batch of ideas and want to code them out before you can think of tests for them. Then it is possible the batch of code will do something that looks like it works, but without tests, you might not really understand what is happening. Tests give you a foundation of understanding. Its like measuring out and cutting each piece of wood for a house to exact specifications and knowing for certain that every piece will fit, rather than lining up a bunch of wood and cutting through them all at once with a giant machete and hoping everything will stand the way you pictured it working out in your mind.
Craftsman 21:
A note on deleting directories, it might be a good idea to check for subdirectories and files in those subdirectories before you delete the primary directory.
Make sure your tests clean up after themselves.
Craftsman 22:
A foreshadow to a grave mistake that I believe Alphonse and Avery are making. To add just a bit of functionality that made a wide range of changes to the code all over the place. All these changes were done without writing new tests and as a chain of changes trying to make the last test work without rethinking their strategy. Although I felt uneasy about this, no note of a mistake was mentioned in the following articles... I am uncertain of the intended message.
Craftsman 23:
An example of pair programming, write the test then have your pair make it pass. StarCraft > LandCraft
Craftsman 24:
A sort of interlude to the next section. Also acceptances tests can help organize the structure of your code.
Craftsman 25:
An explanation of acceptance tests, their purpose as the requirements, and the idea that they can be written by the project managers, and the craftsman make them pass.
Craftsman 26:
Introduction to fitnesse. Writing acceptance tests.
Craftsman 27:
Some what deeper explanation of writting acceptance tests, and a Fitnesse.
A reminder of the need for not only unit tests, but acceptance tests as well, and the importance of the tests having the ability to test the code.
Craftsman 28:
Public vs private fields in classes. Much of OOP is centered around encapsulating variables, data, and ideas, and thus it is often appropriate to use getter and setter methods; however, for data structures that are mostly used to transfer data, getters and setters would be a waste and thus public fields are advisable. With objects, you mostly want private variables, with data structures (such as Fitnesse Fixtures) you can have public variables.
Craftsman 29:
Tests aren't a waste of time.
Another common trend that is being displayed, and easily observed in the real world is a stubbornness to do things the way you have always done them. The wise man isn't the smartest, or the one who always knows what to do, but the one whom corrects his mistakes the moment he sees he was wrong.
Craftsman 30:
Hooking up Fitnesse to the application via fixtures.
Craftsman 31:
For acceptance tests you don't do the simplest thing to make it pass, thats for unit tests. For acceptance tests you need to really make them work, and use unit tests to get you to that point. If you are tempted to use a simple method to solve the acceptance tests, chances are you need more unit tests (unless the solution is actually simple of course).
To deal with a database, without specifically writing functions in the database itself, you can use a gateway/interface. This is an object that knows how to handle the data. Push off decisions about the database for as long as possible.
Day 1
Got intelliJ up and running with my fitnesse project
Beat the crap out of ResponseExaminer, and made first Fitnesse Commit on github
Finished some of the craftsmanship articles, currently at #20
Learn about Template Method Pattern and Decorator Pattern
Established this blog account
Beat the crap out of ResponseExaminer, and made first Fitnesse Commit on github
Finished some of the craftsmanship articles, currently at #20
Learn about Template Method Pattern and Decorator Pattern
Established this blog account
Subscribe to:
Posts (Atom)
