Like probably millions of Americans, I decided that one of my New Year's resolutions was to lose weight. However, I also want to exercise my mind as well as my body. Although I've been somewhat ok in the getting the body in better shape part, I have (in my opinion) neglected my mind.
On Thursday, I decided to do a "sugar detox". For at least one week, and I will attempt two, I will have no refined or processed sugars whatsoever. No desserts, no sodas (gasp!), not even putting jam on muffins, or sugar in my oatmeal. The only sugar I will allow myself will be from fruits or fruit juices (and even with fruit juices, I will dilute it with water 50/50). I am also not going to drink any diet soft drinks, as I don't think these are good for your health. I will be taking some fitness supplements, a whey protein isolate, a branched chain amino acid intra workout drink, and SuperPump 250, a proprietary blend of several things which is meant as a 'pre-workout' energizer. Most of these have sucralose to make them palatable. So the fruits, fruit juices and "fake" sugar in the supplements are the only sweets I will be having for the next two weeks.
This is my third day without any sugar, and so far I feel pretty good. No real cravings or sugar pangs yet. I even did some grocery shopping the other day, and none of the desserts enticed me, which is very surprising. Generally, I buy my food day-to-day. The reason for this is that I often forget to defrost my food, which means I'd have to buy some fast food anyway. So almost every day or every other day, I go to the supermarket to get my food. The benefit to this is that my food is fresh. The downside to this is that I am always tempted to buy bad things (and lord help me....Cadbury Creme eggs are already on sale). So I was surprised that I didn't really linger in the bakery department, and neither did the aisle containing the Cadbury Creme Eggs.
Having been reasonably fit before I injured my knee, I do know how to lose weight. The hard part is the discipline, preparation, and energy. For me, it takes 6 weeks of working out a minimum of 4 days a week to force exercise as a habit. My body tends to lose fat more quickly with weight workouts than cardio, but cardio is necessary for my body at least 3 days a week. Preparation is another overlooked part of losing weight. Trying to eat 5-6 times a day mandates planning your meals. If you don't prepare your meals in advance, you WILL cheat. And the last part, having enough energy is also difficult to do. Having enough energy means that you get 8hrs of solid sleep, eat breakfast, and don't crash on sugar. Sounds simple, but in practice, it's harder for me than it sounds.
The same rules that apply to training the body apply to training the mind. It takes discipline, preparation, and energy. The discipline means that I have to follow through on what I want. Wanting is not enough. Just reading or practicing some homework isn't enough. Preparation means setting aside time for studying, and sticking to it. If I just try and find free time, usually there isn't any. And if I don't force myself to study at a given time, I will procrastinate and find something less strenuous to do. Having energy means having the mental focus to study. Just like a muscle, if your mind is not clear and focused, you won't get a lot of mental benefit.
In order to help me out in both body and mind, I have decided to create a game plan. For my physical training, I am going to get back onto BodySpace and report my progress there. I intend to do the following:
Sat: Cardio
Sun: Cardio
Mon: Upper Body
Tue: Rest
Wed: Lower Body, Cardio
Thu: Arms, Abs
Fri: Rest
Nutrition will be a bit tricky. I'm going to try the grab bag approach, where I pick a protein source, a carb source, and a fruit/veggie source for each meal. I also bought some food containers that should help portion out the meal. Some fitness gurus advocate the "portion size" method, and some say that you must actually count calories, as "eyeballing" it can lead to over or under estimations of caloric food intake. For now, I'm going to go with the "eyeball" approach, and have about a palm sized portion of protein, a palm sized portion of carbs, and a fist sized portion of fruit or veggies (since I'm not a huge veggie person, I'll probably be eating more fruit than veggies...and no, carrots and potatoes don't count as veggies...but broccoli, cauliflower, spinach, most greens, and legumes do count).
For the mental training, I am going to devote an hour a day every weekday to academic training. In the beginning, this is mostly going to consist of relearning a lot of my math. I've always been fascinated by math, but my weakness in the basics always hampered me. To be honest, I usually only did some of my math homework in school, just enough to understand the concept, but not enough to reinforce it as 2nd nature. I also want to get much better at linear and abstract algebra. And of course, I need to get back to basics with my calculus. Once I feel good with my algebras, I need to get better at stochastics, because a lot of interesting problems are random in nature (really, Quantum Mechanics is all about probabilities). And finally, I want to study Number Theory and Numerical Analysis, as I never did those in college.
Some may wonder why I want to study math, and not more computer science-y things. Afterall, I've heard several people tell me that you don't really need or use that much math in real world programming. I think that's a bunch of hooey. I don't want to be good at "real world" programming...I want to understand computer SCIENCE, not software engineering. Furthermore, the truly hard problems to solve require a good background in math. And finally, being better at math will, I think, make me better at programming in general.
I used to tell people who were interested in going into Computer Science if they were good at math. It surprised me how many people said that either A) they weren't good at math, or B) weren't interested in math. I never asked, but I always wondered if these people, like so many, got their interest in programming because they wanted to make computer games. Well, if you want to make computer games, you better be good at math. 3D programming? You better know matrix multiplication and therefore linear algebra. Want to make some cool AI stuff? You better know bayes theorem for some of the more interesting AI techniques. For a good network server, understanding queuing theory and the stochastic nature of processes will come in handy.
Just learning how to program isn't THAT hard. Yes, a good engineer is more than just a programmer (what I mean by this is that a good software engineer understands things like lifecycle design, revision control, documentation, release engineering, unit testing, etc etc. And I think being good at math is what can separate a good engineer from a great one. One of the best quotes I ever heard about the difference between a scientist and an engineer is this:
"Engineers learn in order to build. Scientists build in order to learn"
By that definition, I consider myself a scientist. Building things just to build them or make money off them does not interest me. I build things in order to learn. Right now, most of my learning has simply been to put a new technology in my pocket (which hopefully will look better on my resume). I really only learned the fundamentals of databases for a project at work, and the same for eclipse. I will be learning 3d programming (OpenGL) for my clojure game, and I learned clojure because....well, I like learning languages.
But for me, math isn't just about putting something in my pocket that will make me more attractive to employers. In fact, it's probably something of a detriment. But math is the language of the universe. And just as I like learning programming languages, I want to get better at this universal language called math.
Sunday, January 30, 2011
Saturday, January 29, 2011
Reconsidering GUI platform
So I just found out that JavaFX will be ported as a Java API and thus will become a java library. JavaFX seems to be a more technologically advanced GUI framework than Swing. What caught my eye on the JavaFX roadmap was that it would be hardware graphics accelerated. Unlike Swing, which is rooted in AWT, JavaFX will be able to take advantage of OpenGL or DirectX.
In fact, when I originally started on my clojure project, I had considered using lwjgl and nifty-gui (and possibly even the jmonkeyengine). I had ultimately planned on wanting a 3d view, as I thought this would be a cool feature for the game. A long time ago, even before I had started programming, I had looked at the OpenRPG engine (written in python). While I thought OpenRPG was pretty cool, I wished it had a 3d map/world feature.
So I will go ahead and complete the java launcher project in Swing, but I will then start looking into lwjgl and nifty-gui from here on out. Although jmonkeyengine looks great, and I know (almost) nothing about 3d programming, I doubt jmonkeyengine will be very amenable to using clojure. Besides, this will be an opportunity for me to learn OpenGL from the ground up.
UPDATE:
In fact, when I originally started on my clojure project, I had considered using lwjgl and nifty-gui (and possibly even the jmonkeyengine). I had ultimately planned on wanting a 3d view, as I thought this would be a cool feature for the game. A long time ago, even before I had started programming, I had looked at the OpenRPG engine (written in python). While I thought OpenRPG was pretty cool, I wished it had a 3d map/world feature.
So I will go ahead and complete the java launcher project in Swing, but I will then start looking into lwjgl and nifty-gui from here on out. Although jmonkeyengine looks great, and I know (almost) nothing about 3d programming, I doubt jmonkeyengine will be very amenable to using clojure. Besides, this will be an opportunity for me to learn OpenGL from the ground up.
UPDATE:
I did a little more research, including taking a look at TWL, and a little more into lwjgl, and I think switching to 3d aware GUI platform is the way to go.
I looked a bit at TWL, but none of their java web start demos worked for me, the wiki leads you to a non-existent page, and the documentation like-wise is missing. Basically, not a good way to get me to want to use it. It did however have a scala port and it used mercurial as its VCS system. Yes, I do tend to see how up-to-date people are with a project. If they are still using CVS, I get scared (I'm looking at you Eclipse), and if they are still using subversion, I see them as falling behind (or maybe they are just scared of using repository porting tools to convert from subversion to something like git or mercurial).
So while looking at one of the nifty-gui tutorials, it goes into some detail about how to create your own widget. In other toolkits, this is quite a pain to do, and I thought it was pretty cool to be able to do that. I did notice that all the java 3d gui toolkits used XML as a declarative language. I was thinking that it might not be bad to make a clojure port.
I remember about 10 years ago, on the gamedev.net forum, there was a debate about lisp vs. xml. Essentially anything you can do in xml, you can do in lisp. Now that I have a better handle on clojure, I can see why. In fact, Amit Rathore's book, Clojure in Action tries to dispell the myth that lisp syntax is hard by stripping away parts of xml until it looks like lisp syntax.
Now that I am getting better at clojure, it amazes me that people think Scala is the future for the JVM. Not to pick on Scala, but its hybrid approach means that while programmers will be more comfortable in learning it from a paradigm perspective, it also means that code will be a mish-mosh of functional and impure code. I think Scala is the bad way to go, even though it is clearly better than Java itself. The syntax of clojure was actually pretty easy to get used to, it was just wrapping my brain around functional programming that was hard. I also still haven't quite understood how or when to use macros, and that's one of the next things I want to tackle, and I think I will need to use macros if I wanted to make a clojure API around nifty-gui.
Thursday, January 20, 2011
be here, now
I was browsing on YouTube the other day and as tends to happen, I ran into several old gems. I'm not really a big Queen fan, despite having "Another One Bites the Dust" hammered into my ears as a very young lad, but I did find Queen's song for the Highlander movie, "Who Wants to Live Forever".
Maybe because I found that Brian May is now Dr. May (he earned his doctorate degree in Astrophysics recently), I paid more attention to the song. For the first time, I actually listened to the words...and they struck me as being very buddhist.
If you never saw The Highlander movie (don't bother watching the sequels, though the TV series was pretty good actually), basically it's about a group of mysterious immortals that can only be killed by having their heads cut off. Imagine for a second being able to live forever, and yet watching those you love around you die.
You don't even really have to be immortal to understand that. I have a dog named Aiko, and she is very dear to me, and I always thought it a cruel irony that dogs live 1/5th as long as humans do, despite in my opinion, dogs being superior to humans in many ways. One day, I will have to watch her leave, and the thought always fills me with sadness despite the fact that I know that this is simply the way things are.
So I listened to the lyrics of the song, and basically the recurring theme is, who wants to live forever, if love has to die. I saw some comments on YouTube from some christians saying that they will live forever one day in a different place. But buddhists do not ascribe to these beliefs. For us, this is nothing more than wish-fulfillment, yet another desire that leads to suffering. Humans have been ingrained to not see things as they are, but as to how we expect them to be, conceive them to be or hope them to be. Our everyday experience tells us that things are not permanent, and yet we still try to fool ourselves into believing that there is more to life than meets our experiences.
One of the parts of the song says that "forever is our today". This is exactly what Zen means when it says that we must live now in the present. The past is gone, and the future is not yet here. All we truly have is this moment now. Sometimes, when I take Aiko for a walk, I drop as much baggage as I can, and I am always amazed by two things:
1) how peaceful it is
2) how hard it is to stay that way
Always, some thought or some sensation brings me back to the world of "inner mind", where I think about things past, present or future that have nothing to do with "right now". Our minds are always scattered and not experiencing what life is presenting to us. Instead, we think about how much work we have to do, or errands we have to run, or we reminisce about something, etc etc. But if we could only pay attention to "right now", we would be pretty amazed.
The song also struck me as buddhist in that it shows how pain comes from love. There is a story about buddhism that I have always liked, because it illustrates how suffering can come from anything...including love. Most people think that "love burns eternal", or that love saves the day....yadda yadda. Again, this is wishful thinking. The truth is that like all things, love changes. It grows, and it fades away or at least it changes. The only true lasting love is the kind that accepts the loved for whatever it is, not as you want it to be. But let me get back to the buddhist story.
King Pasenadi was a king of a neighboring country of the Buddha's own land (Sakya). He was a nominal Hindu, but his wife had heard of the Buddha's teaching and was enamored of them. One day, the Buddha was traveling in King Pasenadi's kingdom, and he met a man who was weeping in sorrow. The Buddha asked the man why he was filled with grief, and the man told the Buddha that his son had died. The Buddha said that "in love there is suffering", but before the Buddha could explain more, the man angrily retorted that love only brings happiness and joy and then he ran off.
The man soon talked with other people in town, and the other people agreed with the man, saying that it was wrong of the Buddha to claim that love was suffering. Eventually, word reached King Pasenadi's ears and he told his wife that "this monk called 'The Buddha' may not be as spiritual as you think". When his wife (Mallika) asked him why, King Pasenadi told her that the Buddha taught that love was suffering. Later Mallika asked an attendant to ask the Buddha what he had meant to say. When the attendant (a Brahman) had come back and explained what the Buddha had tried to say, Mallika understood the Buddha's intent.
When King Pasenadi was relaxing, Mallika came to him and asked, "My husband, do you love Princess Vajiri?". King Pasenadi was somewhat taken aback. He replied, "Of course I do". So Mallika continued, "And would you be distressed if something were to befall her?". The King seemed troubled, for he was wise enough to see where his wife was going with this, and the King resolved to meet the Buddha.
The King asked the Buddha that he could see how pain and suffering could stem from love, but that joy and happiness also sprang from love. The Buddha's answer is very important, and this answer also applies to meekness. The Buddha replied that the majority of people in the world conceived of love in terms of "me" or "mine". Because of this, love was mired in the world of separation and attachments. When most people think of love, they think only what they will get out of it. Love that thinks of self, or me, or mine is not true love. True love only thinks of others or of the whole...never the self. The Buddha said that there are only two kinds of love; karuna, which is the love that brings happiness to others and maitri which eases the sufferings of others (btw, the future Buddha is said to be Maitreya...the one who ends suffering). In both karuna and maitri, there is no thought of getting something in return.
I love this story because it points to the heart of our selfishness. True love is selfless. It seeks nothing in return except to share happiness, or to ease suffering. Nowhere does it say, "in return for loving you, I expect something in return". Nowhere does it say that love is eternal.
We must love everything. We must have loving kindness to all things, not just things that we find agreeable to us. For me, this is one of the hardest aspects to follow in Buddhism. There are many things in this world that I don't like. And yet I need to understand how we are all connected, and how we are all under delusion. It is never a matter of forcing yourself into a belief or practice. If you force yourself to be celibate while having lustful thoughts, or force yourself to be charitable when giving to others, or give only when expecting to be rewarded...these are false attainments).
Maybe because I found that Brian May is now Dr. May (he earned his doctorate degree in Astrophysics recently), I paid more attention to the song. For the first time, I actually listened to the words...and they struck me as being very buddhist.
If you never saw The Highlander movie (don't bother watching the sequels, though the TV series was pretty good actually), basically it's about a group of mysterious immortals that can only be killed by having their heads cut off. Imagine for a second being able to live forever, and yet watching those you love around you die.
You don't even really have to be immortal to understand that. I have a dog named Aiko, and she is very dear to me, and I always thought it a cruel irony that dogs live 1/5th as long as humans do, despite in my opinion, dogs being superior to humans in many ways. One day, I will have to watch her leave, and the thought always fills me with sadness despite the fact that I know that this is simply the way things are.
So I listened to the lyrics of the song, and basically the recurring theme is, who wants to live forever, if love has to die. I saw some comments on YouTube from some christians saying that they will live forever one day in a different place. But buddhists do not ascribe to these beliefs. For us, this is nothing more than wish-fulfillment, yet another desire that leads to suffering. Humans have been ingrained to not see things as they are, but as to how we expect them to be, conceive them to be or hope them to be. Our everyday experience tells us that things are not permanent, and yet we still try to fool ourselves into believing that there is more to life than meets our experiences.
One of the parts of the song says that "forever is our today". This is exactly what Zen means when it says that we must live now in the present. The past is gone, and the future is not yet here. All we truly have is this moment now. Sometimes, when I take Aiko for a walk, I drop as much baggage as I can, and I am always amazed by two things:
1) how peaceful it is
2) how hard it is to stay that way
Always, some thought or some sensation brings me back to the world of "inner mind", where I think about things past, present or future that have nothing to do with "right now". Our minds are always scattered and not experiencing what life is presenting to us. Instead, we think about how much work we have to do, or errands we have to run, or we reminisce about something, etc etc. But if we could only pay attention to "right now", we would be pretty amazed.
The song also struck me as buddhist in that it shows how pain comes from love. There is a story about buddhism that I have always liked, because it illustrates how suffering can come from anything...including love. Most people think that "love burns eternal", or that love saves the day....yadda yadda. Again, this is wishful thinking. The truth is that like all things, love changes. It grows, and it fades away or at least it changes. The only true lasting love is the kind that accepts the loved for whatever it is, not as you want it to be. But let me get back to the buddhist story.
King Pasenadi was a king of a neighboring country of the Buddha's own land (Sakya). He was a nominal Hindu, but his wife had heard of the Buddha's teaching and was enamored of them. One day, the Buddha was traveling in King Pasenadi's kingdom, and he met a man who was weeping in sorrow. The Buddha asked the man why he was filled with grief, and the man told the Buddha that his son had died. The Buddha said that "in love there is suffering", but before the Buddha could explain more, the man angrily retorted that love only brings happiness and joy and then he ran off.
The man soon talked with other people in town, and the other people agreed with the man, saying that it was wrong of the Buddha to claim that love was suffering. Eventually, word reached King Pasenadi's ears and he told his wife that "this monk called 'The Buddha' may not be as spiritual as you think". When his wife (Mallika) asked him why, King Pasenadi told her that the Buddha taught that love was suffering. Later Mallika asked an attendant to ask the Buddha what he had meant to say. When the attendant (a Brahman) had come back and explained what the Buddha had tried to say, Mallika understood the Buddha's intent.
When King Pasenadi was relaxing, Mallika came to him and asked, "My husband, do you love Princess Vajiri?". King Pasenadi was somewhat taken aback. He replied, "Of course I do". So Mallika continued, "And would you be distressed if something were to befall her?". The King seemed troubled, for he was wise enough to see where his wife was going with this, and the King resolved to meet the Buddha.
The King asked the Buddha that he could see how pain and suffering could stem from love, but that joy and happiness also sprang from love. The Buddha's answer is very important, and this answer also applies to meekness. The Buddha replied that the majority of people in the world conceived of love in terms of "me" or "mine". Because of this, love was mired in the world of separation and attachments. When most people think of love, they think only what they will get out of it. Love that thinks of self, or me, or mine is not true love. True love only thinks of others or of the whole...never the self. The Buddha said that there are only two kinds of love; karuna, which is the love that brings happiness to others and maitri which eases the sufferings of others (btw, the future Buddha is said to be Maitreya...the one who ends suffering). In both karuna and maitri, there is no thought of getting something in return.
I love this story because it points to the heart of our selfishness. True love is selfless. It seeks nothing in return except to share happiness, or to ease suffering. Nowhere does it say, "in return for loving you, I expect something in return". Nowhere does it say that love is eternal.
We must love everything. We must have loving kindness to all things, not just things that we find agreeable to us. For me, this is one of the hardest aspects to follow in Buddhism. There are many things in this world that I don't like. And yet I need to understand how we are all connected, and how we are all under delusion. It is never a matter of forcing yourself into a belief or practice. If you force yourself to be celibate while having lustful thoughts, or force yourself to be charitable when giving to others, or give only when expecting to be rewarded...these are false attainments).
Sunday, January 16, 2011
Ahhhh, recursion
I had a talk with a coworker of mine where he chided some people for writing recursive functions in embedded code. While admittedly you do need to be careful in certain languages in certain environments (where you might have a small stack space), I still think recursion has gotten a bum wrap. I'm surprised how many of my colleagues dismiss recursion out of hand. Of course the vast majority of my coworkers are also C programmers which explains a lot.
I realized at work today that I have done more recursive functions in the last 5 months than in my 4 years of working, 3 years of school, and my 1yr of programming prior to going to school (notice how employers never count the programming you did in school?). I actually ran into a perplexing problem that at first I thought I could solve iteratively, but I eventually wound up doing recursively.
The hardest part for me about recursion is knowing where in the call stack I am, and knowing when I should return some value I want. For example, let's do a simple interest calculator function in python...
Do you see the problem with the above function? No? Look at the return. It appears that the base case is when years == 0, so we fall into the else statement and we return the principal right?
Not exactly. Remember what we are actually doing...we are chaining together a series of functions, so ask yourself what really is returning? The correct function would be this:
Note that the clojure function goes through the loop one less time than the above python equivalent. In some ways, recursion in clojure is easier than it is in mutable languages, because the changing state is always being rebound. If anything the loop/recur in clojure is more similar to a while loop than anything else. In clojure, the function can directly call itself (self-recursion) but then you have to watch out about potential stack overflow problems. That's why it's better to use the loop/recur form when possible.
I realized at work today that I have done more recursive functions in the last 5 months than in my 4 years of working, 3 years of school, and my 1yr of programming prior to going to school (notice how employers never count the programming you did in school?). I actually ran into a perplexing problem that at first I thought I could solve iteratively, but I eventually wound up doing recursively.
The hardest part for me about recursion is knowing where in the call stack I am, and knowing when I should return some value I want. For example, let's do a simple interest calculator function in python...
def calcInterest(principal, savings, interest, years):
yearly_interest = principal * interest
principal += savings + yearly_interest
print "%d: Principal = %d\n" % (years, principal)
if years:
calcInterest(principal, savings, interest, (years - 1))
else:
return principal
Do you see the problem with the above function? No? Look at the return. It appears that the base case is when years == 0, so we fall into the else statement and we return the principal right?
Not exactly. Remember what we are actually doing...we are chaining together a series of functions, so ask yourself what really is returning? The correct function would be this:
def calcInterest(principal, savings, interest, years):
yearly_interest = principal * interest
principal += savings + yearly_interest
print "%d: Principal = %d\n" % (years, principal)
if years:
return calcInterest(principal, savings, interest, (years - 1))
else:
return principal
I have been bitten enough by this that I thought I would pass it along. Of course, recursion in a language like python or Java which has mutable objects is different from clojure where the objects are immutable. So how would I write a interest calculate in clojure?
(defn calc-interest
[ principal savings interest years ]
(loop [ p principal
y years ]
(if (= 0 y)
p
(recur (+ (* p interest) savings p) (dec y)))))
[ principal savings interest years ]
(loop [ p principal
y years ]
(if (= 0 y)
p
(recur (+ (* p interest) savings p) (dec y)))))
Tuesday, January 4, 2011
My own SDLC
If I don't have ADD, then I definitely get too interested in things too easily. There's so much I want to learn about that it's sometimes hard for me to focus on getting something done.
The great irony is that this is something I complain about at work. I am constantly getting pulled off one project in order to fight a fire with something else. As a consequence, it is difficult to get anything done. Previously, I was criticized for not being a good multitasker, but I no longer believe this is the case and more senior engineers have backed me up.
But the fact of the matter is, I need to simultaneously work on the sojourner project, including everything it entails. Currently, the part I am working most on sojourner is just the launcher sub-project. But eventually this thing is going to become a game. On top of the launcher, I need to work on the documentation (which is in the design folder by the way), a web project (to view the documentation and do a few other things...most likely create characters), and I need to create some database tables for several things (the clojure launcher will use it to save classpaths, jar files, etc, and the game will use it to store in-game data).
Unfortunately, my experience with databases is limited, and my web programming next to non-existent. A few months back, I bought a book on servlets and JSP, but I didn't get far into the book. Although I don't mind learning about servlets (I intend to use jetty as a combined servlet container and web server) I'm not really all that interested in JSP since there seems to be a lot of negative flak around it (and templating languages in general, but JSP and even PHP really seem to get it). Since I my knowledge of SQL is very limited, and my web-fu is even worse, that means I'll have to learn these as I go. Nothing new for me, but it will definitely slow down the pace of the project.
I will however soon be putting up a separate open source project for the webpage. I think I will use TurboGears as the framework, since I have read a little about Pylons, and it seems to be a model I am more comfortable with. On the one hand, Django definitely has more uptake, and for my career, it'd probably make better sense to use and learn Django. But I don't like how Django forces you to choose its way of doing things (for example, you have to use it's ORM which others have said only works for a limited set of use-cases). TurboGears and to a greater degree Pylons is more flexible, even if it doesn't hold your hand as much.
And besides, getting better at SQL and web programming can't hurt my career. It seems like most jobs that aren't at the hardware level require some kind of knowledge of databases, and web programming isn't far behind. While doing embedded programming is neat (there's nothing like actually getting physical hardware to work), I think EE and CE's are better suited to that work than I am.
So right now, I've been reading through TurboGears and created a real simple quickstart project. There's quite a bit of reStructuredText documentation that I've been working on for my homebrew game, but there's no place to put it. There's also the disadvantage that the docs are all static. I'd like to be able to make the documentation dynamic and generated on the fly...for example when trying to cross-reference some documentation.
Also, I've been looking at some of the hsqldb documentation, and it's a little bit different than what I've seen in postgresql or MySQL (for example, in-memory tables versus cached tables). The advantage is that I've got complete control of it in Java which will be useful for clojure. But still, I'm wondering if I should ditch hsqldb and just go with sqlite or postgresql. I'll probably need to do a little bit more research into this before I make a decision.
It's at this point I'd like to point out my SDLC. I'm not a big fan of waterfall, scrumm, etc. I do like SOME of agile development, but I think these formalized SDLC methods are a bit constraining. Especially because I am unsure of the technology myself, I program in what I call a research, prototype and enhance loop (RPE for short). I have seen before first hand the absolutely disastrous result of a certain technology chosen and used without any kind of research done into the costs of using said technology. It may seem like a no-brainer to some, but having proof-of-concepts built, or at least a case study of the pros and cons of a technology should be done. But believe or not, this is often not done. Perhaps management feels that spending 3 months on a proof-of concept or getting all the pros and cons is a waste of time. After all, aren't all programming languages the same? Doesn't XMLRPC, SOAP, RMI and JSON-RPC all do remote procedures? And in all earnestness, is there really any difference between Wicket, Tapestry, Ruby On Rails, Django or Lift (etc etc)?
If you think there are no tangible differences to any of these scenarios....you sir, don't deserve to make decisions. All things have their pros and cons, and a job of an architect is to make sure that the pros help solve your problem domain, and the cons don't add (significantly) to them. Of course, how do you know what the pros and cons are? Are reviews on places like stackoverflow, reddit, etc really reliable?
That's where proof-of-concepts come in. Do something simple in the technologies you are interested in and see how difficult they are. I'll give you a real world example. Due to some dissatisfaction with the way SWIG worked, I had been researching some alternatives. I had played with python's ctype module, and it had some features better than SWIG (such as for example, it was highly obvious when python code had to interface with C code), though it also had some problems. One of the problems was keeping up with API changes. While SWIG could take header files of the C program, with ctypes, there was no such thing. And unfortunately, despite the fact that you SHOULDNT break an API without going to a new major release, it happened all too frequently for us. When we started playing around with Java, I started looking at ways for Java to make calls into a C shared library. The old-fashioned way was JNI, and I had looked a little bit at before and shuddered. I had heard of a library called JNA which promised to do away with JNI. While JNA looks nice (it's kind of like ctypes), it required quite a bit of work to get the correct Java class matched with the correct C struct. I then went back and tried a few JNI examples, and I found it wasn't nearly as bad as I thought.
The point of the story is that I actually USED all these technologies, even if just a little bit. I got my hands just dirty enough to see for myself what the implications and limitations would be. Does that mean that I would know everything? No, but along with the reviews I see online, I now had a more informed decision.
So that covers the research part, what about the prototype part? This is where I do something like Agile programming. I believe that code projects of any size which has more than one developer is alive, and thus subject to "code rot". Basically, code evolves, often unplanned (which is why I sometimes call my programming style "organic" programming). When you are faced with a problem, it's best to model the problem as simply as you can. This means making assumptions, often not making code robust to handle unusual input, etc. But at least some functionality is made. The key here is not letting others then take your code as production quality (which happens all too often). In prototype code, the key is documentation, documentation, documentation. Document that your code only handles certain code paths. Document what it is doing and what still needs to do. Don't be afraid to have a code to documentation ratio of 1:1 or even more.
The reason documentation is so important is that prototyping leads to an informal and dynamic programming style. While you are coding something, an idea may quickly pop into your head. Rather than stop your idea, and then add some Enhancement Request (or god forbid, use UCM enabled ClearQuest where you have to link every code change to some CM activity) just go with the flow. The one thing you may want to be disciplined about is branching your code or forking off a new clone...which is why DCVS's are much better than CVCS like subversion. It's trivial to create a new repo or branch and thus isolate your new idea. While merging isn't as easy as mercurial or git makes it sound, it's no worse than what you would have to do with subversion or ClearCase anyway.
So now that you have some prototype code, it's time to enhance it. You will have bugs, and you will lots of TODOs, so it's time to go back and fix those. I like to complete the enhancements and bugs before tackling new enhancement requests, otherwise, your prototyped code will never get to a "stable" point. So the Prototype and Enhancement phases are in a feedback loop, and eventually they get done.
Well, what about getting requirements? Ahhh, the bane of my life. In my experience, getting requirements from non-technical people is like pulling teeth....mine and the client. This is where rapid prototyping is supposed to help. If you can come up with a limited functionality program, the client can give feedback on what they like or don't like, or help prioritize the still TODO items. Sadly, it is my experience that clients will often take the prototype code as-is, because they too are under time pressure, and of course the quality sucks. This is the danger of prototyped code. But in my opinion, if you do due diligence and inform the client of the shortcomings, they have no one to blame but themselves.
Prototyping still doesn't help you get the very first requirements though. I haven't ever used UML use cases or scrumm cards or anything like that. For my own personal project, I simply ask myself what I would like, and then I write it down. I then later try to scope out the difficulty of the requirements, and determine a priority (or dependency).
Yes, my SDLC is very informal. Some might even laugh at it. But software engineering isn't engineering like mechanical or electrical engineering. Software Engineering is still in its infancy, and is more like a craft. I see myself more as an artisan than anything. And yes, coding is an art.
Not to rip on EE's, but I can't tell you how many 600+ line functions I have seen (and no, I don't buy the argument that pushing a new function on the call stack is THAT expensive...inline for crying out loud), or programs that were 30,000+ lines of code, that had no header files or were broken into sub-modules (ummmm, you do know that you can compile your code into into .o, .a, or .so files and link to them??). While I have no clue how MOSFETs work, I do think I can code better than 80% of the EE's out there that I have seen. And when I say code better, I don't mean code better bit shift functions, or create some weird function pointer callback that takes 15 minutes to look at and figure out what the return type is (man I hate function pointers that take function pointers as args....that's why dynamic functional languages rock). But when I say I can code better, it means my documentation is much better, my code is broken down into manageable chunks (that don't require me to step through 800 lines of code to figure out where exactly the problem is that I got from a backtrace), and I can actually design better (code libraries rather than a monolithic gargantuan executable without function declarations in the c source itself....which is ok if you have a private API).
Remember what Guido Van Rossum said, code is read far more often than it is written. And remember what General Patton said when asked about being a good leader, "don't give great orders, give orders that can be understood". Design cleanly, code often, fix often and repeat.
The great irony is that this is something I complain about at work. I am constantly getting pulled off one project in order to fight a fire with something else. As a consequence, it is difficult to get anything done. Previously, I was criticized for not being a good multitasker, but I no longer believe this is the case and more senior engineers have backed me up.
But the fact of the matter is, I need to simultaneously work on the sojourner project, including everything it entails. Currently, the part I am working most on sojourner is just the launcher sub-project. But eventually this thing is going to become a game. On top of the launcher, I need to work on the documentation (which is in the design folder by the way), a web project (to view the documentation and do a few other things...most likely create characters), and I need to create some database tables for several things (the clojure launcher will use it to save classpaths, jar files, etc, and the game will use it to store in-game data).
Unfortunately, my experience with databases is limited, and my web programming next to non-existent. A few months back, I bought a book on servlets and JSP, but I didn't get far into the book. Although I don't mind learning about servlets (I intend to use jetty as a combined servlet container and web server) I'm not really all that interested in JSP since there seems to be a lot of negative flak around it (and templating languages in general, but JSP and even PHP really seem to get it). Since I my knowledge of SQL is very limited, and my web-fu is even worse, that means I'll have to learn these as I go. Nothing new for me, but it will definitely slow down the pace of the project.
I will however soon be putting up a separate open source project for the webpage. I think I will use TurboGears as the framework, since I have read a little about Pylons, and it seems to be a model I am more comfortable with. On the one hand, Django definitely has more uptake, and for my career, it'd probably make better sense to use and learn Django. But I don't like how Django forces you to choose its way of doing things (for example, you have to use it's ORM which others have said only works for a limited set of use-cases). TurboGears and to a greater degree Pylons is more flexible, even if it doesn't hold your hand as much.
And besides, getting better at SQL and web programming can't hurt my career. It seems like most jobs that aren't at the hardware level require some kind of knowledge of databases, and web programming isn't far behind. While doing embedded programming is neat (there's nothing like actually getting physical hardware to work), I think EE and CE's are better suited to that work than I am.
So right now, I've been reading through TurboGears and created a real simple quickstart project. There's quite a bit of reStructuredText documentation that I've been working on for my homebrew game, but there's no place to put it. There's also the disadvantage that the docs are all static. I'd like to be able to make the documentation dynamic and generated on the fly...for example when trying to cross-reference some documentation.
Also, I've been looking at some of the hsqldb documentation, and it's a little bit different than what I've seen in postgresql or MySQL (for example, in-memory tables versus cached tables). The advantage is that I've got complete control of it in Java which will be useful for clojure. But still, I'm wondering if I should ditch hsqldb and just go with sqlite or postgresql. I'll probably need to do a little bit more research into this before I make a decision.
It's at this point I'd like to point out my SDLC. I'm not a big fan of waterfall, scrumm, etc. I do like SOME of agile development, but I think these formalized SDLC methods are a bit constraining. Especially because I am unsure of the technology myself, I program in what I call a research, prototype and enhance loop (RPE for short). I have seen before first hand the absolutely disastrous result of a certain technology chosen and used without any kind of research done into the costs of using said technology. It may seem like a no-brainer to some, but having proof-of-concepts built, or at least a case study of the pros and cons of a technology should be done. But believe or not, this is often not done. Perhaps management feels that spending 3 months on a proof-of concept or getting all the pros and cons is a waste of time. After all, aren't all programming languages the same? Doesn't XMLRPC, SOAP, RMI and JSON-RPC all do remote procedures? And in all earnestness, is there really any difference between Wicket, Tapestry, Ruby On Rails, Django or Lift (etc etc)?
If you think there are no tangible differences to any of these scenarios....you sir, don't deserve to make decisions. All things have their pros and cons, and a job of an architect is to make sure that the pros help solve your problem domain, and the cons don't add (significantly) to them. Of course, how do you know what the pros and cons are? Are reviews on places like stackoverflow, reddit, etc really reliable?
That's where proof-of-concepts come in. Do something simple in the technologies you are interested in and see how difficult they are. I'll give you a real world example. Due to some dissatisfaction with the way SWIG worked, I had been researching some alternatives. I had played with python's ctype module, and it had some features better than SWIG (such as for example, it was highly obvious when python code had to interface with C code), though it also had some problems. One of the problems was keeping up with API changes. While SWIG could take header files of the C program, with ctypes, there was no such thing. And unfortunately, despite the fact that you SHOULDNT break an API without going to a new major release, it happened all too frequently for us. When we started playing around with Java, I started looking at ways for Java to make calls into a C shared library. The old-fashioned way was JNI, and I had looked a little bit at before and shuddered. I had heard of a library called JNA which promised to do away with JNI. While JNA looks nice (it's kind of like ctypes), it required quite a bit of work to get the correct Java class matched with the correct C struct. I then went back and tried a few JNI examples, and I found it wasn't nearly as bad as I thought.
The point of the story is that I actually USED all these technologies, even if just a little bit. I got my hands just dirty enough to see for myself what the implications and limitations would be. Does that mean that I would know everything? No, but along with the reviews I see online, I now had a more informed decision.
So that covers the research part, what about the prototype part? This is where I do something like Agile programming. I believe that code projects of any size which has more than one developer is alive, and thus subject to "code rot". Basically, code evolves, often unplanned (which is why I sometimes call my programming style "organic" programming). When you are faced with a problem, it's best to model the problem as simply as you can. This means making assumptions, often not making code robust to handle unusual input, etc. But at least some functionality is made. The key here is not letting others then take your code as production quality (which happens all too often). In prototype code, the key is documentation, documentation, documentation. Document that your code only handles certain code paths. Document what it is doing and what still needs to do. Don't be afraid to have a code to documentation ratio of 1:1 or even more.
The reason documentation is so important is that prototyping leads to an informal and dynamic programming style. While you are coding something, an idea may quickly pop into your head. Rather than stop your idea, and then add some Enhancement Request (or god forbid, use UCM enabled ClearQuest where you have to link every code change to some CM activity) just go with the flow. The one thing you may want to be disciplined about is branching your code or forking off a new clone...which is why DCVS's are much better than CVCS like subversion. It's trivial to create a new repo or branch and thus isolate your new idea. While merging isn't as easy as mercurial or git makes it sound, it's no worse than what you would have to do with subversion or ClearCase anyway.
So now that you have some prototype code, it's time to enhance it. You will have bugs, and you will lots of TODOs, so it's time to go back and fix those. I like to complete the enhancements and bugs before tackling new enhancement requests, otherwise, your prototyped code will never get to a "stable" point. So the Prototype and Enhancement phases are in a feedback loop, and eventually they get done.
Well, what about getting requirements? Ahhh, the bane of my life. In my experience, getting requirements from non-technical people is like pulling teeth....mine and the client. This is where rapid prototyping is supposed to help. If you can come up with a limited functionality program, the client can give feedback on what they like or don't like, or help prioritize the still TODO items. Sadly, it is my experience that clients will often take the prototype code as-is, because they too are under time pressure, and of course the quality sucks. This is the danger of prototyped code. But in my opinion, if you do due diligence and inform the client of the shortcomings, they have no one to blame but themselves.
Prototyping still doesn't help you get the very first requirements though. I haven't ever used UML use cases or scrumm cards or anything like that. For my own personal project, I simply ask myself what I would like, and then I write it down. I then later try to scope out the difficulty of the requirements, and determine a priority (or dependency).
Yes, my SDLC is very informal. Some might even laugh at it. But software engineering isn't engineering like mechanical or electrical engineering. Software Engineering is still in its infancy, and is more like a craft. I see myself more as an artisan than anything. And yes, coding is an art.
Not to rip on EE's, but I can't tell you how many 600+ line functions I have seen (and no, I don't buy the argument that pushing a new function on the call stack is THAT expensive...inline for crying out loud), or programs that were 30,000+ lines of code, that had no header files or were broken into sub-modules (ummmm, you do know that you can compile your code into into .o, .a, or .so files and link to them??). While I have no clue how MOSFETs work, I do think I can code better than 80% of the EE's out there that I have seen. And when I say code better, I don't mean code better bit shift functions, or create some weird function pointer callback that takes 15 minutes to look at and figure out what the return type is (man I hate function pointers that take function pointers as args....that's why dynamic functional languages rock). But when I say I can code better, it means my documentation is much better, my code is broken down into manageable chunks (that don't require me to step through 800 lines of code to figure out where exactly the problem is that I got from a backtrace), and I can actually design better (code libraries rather than a monolithic gargantuan executable without function declarations in the c source itself....which is ok if you have a private API).
Remember what Guido Van Rossum said, code is read far more often than it is written. And remember what General Patton said when asked about being a good leader, "don't give great orders, give orders that can be understood". Design cleanly, code often, fix often and repeat.
Saturday, January 1, 2011
Lots of things to learn
There are still lots of things to work on:
1. I need to allow the user to choose if executing a jar (to add the -jar option)
2. I need a field to choose the actual jar to execute or the class with the main function to run
3. I should add paths for clojure, jython, jruby, scala, etc
4. All these settings need to be saved to a database (HSQLDB)
5. The settings should be savable with tags
6. Have to come up with a repl-socket-server (clojure.contrib.server-socket)
7. I'd like to create a jython remote repl also
8. Given the configuration, it should generate a launch script
9. Integrate with leiningen/cake by reading a project.clj file
In other words, I've got loads to do. My knowledge of SQL is pretty weak, so another big challenge will be learning HSQLDB on top of everything else. I'm not a swing guru either, so I am basically reading up on Swing as I go.
Since there is so much configuration information going on, I'll probably have to separate them out in tab panels or as dialogs that popup from a menu action. Even though I am going the database route to hold the settings, I still should probably save a particular instance to a file. Since this IS Clojure, and data is code, I want to save the config info as clojure code.
1. I need to allow the user to choose if executing a jar (to add the -jar option)
2. I need a field to choose the actual jar to execute or the class with the main function to run
3. I should add paths for clojure, jython, jruby, scala, etc
4. All these settings need to be saved to a database (HSQLDB)
5. The settings should be savable with tags
6. Have to come up with a repl-socket-server (clojure.contrib.server-socket)
7. I'd like to create a jython remote repl also
8. Given the configuration, it should generate a launch script
9. Integrate with leiningen/cake by reading a project.clj file
In other words, I've got loads to do. My knowledge of SQL is pretty weak, so another big challenge will be learning HSQLDB on top of everything else. I'm not a swing guru either, so I am basically reading up on Swing as I go.
Since there is so much configuration information going on, I'll probably have to separate them out in tab panels or as dialogs that popup from a menu action. Even though I am going the database route to hold the settings, I still should probably save a particular instance to a file. Since this IS Clojure, and data is code, I want to save the config info as clojure code.
Subscribe to:
Posts (Atom)