So, I am currently doing a big coding project, codenamed "Joe", and I have an observation I wanted to share.
I seem to be going through three steps in my development process:
- General planning
- Coding to deliver functionality
- Unit testing and optimization
Now, part of this is due to my impatient nature. I want the results as soon as possible. In theory, I could do more of the optimization during the planning stage, and more of the unit testing during coding.
However, I think there is also a valid point that not all code requirements can be planned out. Some obstacles or "inspiration" may occur during coding, and then we still need the optimization step at the end.
Incidentally, I liken the optimization step to taking the parts of a machine out, cleaning them and going over them, then putting them back in.
Showing posts with label coding. Show all posts
Showing posts with label coding. Show all posts
2008-12-03
CODING: Add "compare" to "get" and "set"
For the coders out there, you may be familiar with C#, and how it includes "get" and "set" functions. I was thinking there should be a third function called "compare". Many times in code, I need to know if a value matches what an object has in a property. Rather than using "get" and writing extraneous code over and over, why not a simple "compare"?
Example:
tempvar = object.property.get()
if (tempvar = comparevar) ...
if (object.property.compare(comparevar)) ...
It probably gets more complicated than that, but you get the idea
Example:
tempvar = object.property.get()
if (tempvar = comparevar) ...
if (object.property.compare(comparevar)) ...
It probably gets more complicated than that, but you get the idea
2008-11-06
CODING: Modular coding techniques
Totally unnecessary disclaimer: I do not claim to be any kind of authority when it comes to programming. The following are just observations.
For more modular coding, I would like to mention two techniques.
First: code for unit testing. This means to write your methods in such a way that it is easy to test each method in an "offline" setting to make sure the method produces expected values given certain input. In this way, if you make changes to the method, you can test the method before and after to make sure the output is the same for both instances.
The trick in this case is to develop methods so that they do indeed work offline. For example. I was just editing a method that creates a SQL query using arguments passed to the method, executes the query, then returns the results. For unit testing, the part where the query is build should be in its own method (separated from the database part), so that you can test it with input when you change the method of building the query.
Second: modularize everything (sorry for making a verb by adding "ize"). Every part of an application should be modularized so that changing one part does not require changing other parts. For example, I have an application that accepts input from an excel spreadsheet and produces PHP code. However, many methods in the application contribute to the final output. What I should do is have all of those methods call a common output method, and have that write to the final output. In this way, if I decide to output in different mediums, I only have to change the output method, rather than the multiple methods.
For more modular coding, I would like to mention two techniques.
First: code for unit testing. This means to write your methods in such a way that it is easy to test each method in an "offline" setting to make sure the method produces expected values given certain input. In this way, if you make changes to the method, you can test the method before and after to make sure the output is the same for both instances.
The trick in this case is to develop methods so that they do indeed work offline. For example. I was just editing a method that creates a SQL query using arguments passed to the method, executes the query, then returns the results. For unit testing, the part where the query is build should be in its own method (separated from the database part), so that you can test it with input when you change the method of building the query.
Second: modularize everything (sorry for making a verb by adding "ize"). Every part of an application should be modularized so that changing one part does not require changing other parts. For example, I have an application that accepts input from an excel spreadsheet and produces PHP code. However, many methods in the application contribute to the final output. What I should do is have all of those methods call a common output method, and have that write to the final output. In this way, if I decide to output in different mediums, I only have to change the output method, rather than the multiple methods.
2008-10-21
CODING: Getting computers to understand human speech
One bit of coding I have in mind to develop (public license of course) is a kind of language interpreter.
The premise: why can't we tell our computers what to do instead of moving around a mouse and typing on a keyboard?
As far as simple sentences go, it shouldn't be hard. The only difficult piece will be code that converts spoken words to text that the computer can parse, e.g. ANSI (or ASCII?)
After that, it comes down to linguistic rules. Here is an example, using two languages to show versatility.
Rule for identifying the weekday:
English:
Japanese:
Rule for {weekday} (with a pipe "|" indiciating "or"):
Rule for {sunday}:
English:
Japanese:
Same for the other days of the week.
For possible mis-translations, the pattern would be something like this:
When the rule matches something said by the user, you could use logic like the following:
And it would follow for the rest of the weekdays.
This somewhat mimics human memory recall. If a person asked what day it was, upon hearing an answer, their mind would search through their memory for things to remember on that particular day.
The premise: why can't we tell our computers what to do instead of moving around a mouse and typing on a keyboard?
As far as simple sentences go, it shouldn't be hard. The only difficult piece will be code that converts spoken words to text that the computer can parse, e.g. ANSI (or ASCII?)
After that, it comes down to linguistic rules. Here is an example, using two languages to show versatility.
Rule for identifying the weekday:
English:
"Today is {weekday}"Japanese:
"Kyou wa {weekday} desu"Rule for {weekday} (with a pipe "|" indiciating "or"):
"{sunday}|{monday}|..."
Rule for {sunday}:
English:
"sunday"Japanese:
"nichiyoubi"Same for the other days of the week.
For possible mis-translations, the pattern would be something like this:
"sunday|(sunny day)|..."
When the rule matches something said by the user, you could use logic like the following:
if ({Today rule hit})
if ({weekday} = {sunday})
{code for sunday}
And it would follow for the rest of the weekdays.
This somewhat mimics human memory recall. If a person asked what day it was, upon hearing an answer, their mind would search through their memory for things to remember on that particular day.
Subscribe to:
Posts (Atom)