• Broadening my horizons - Object oriented Lua

    9/29/2008 9:38:30 PM

    I decided the other weekend to learn a new language, not because i had the 'hankering' to get sick with frustration of syntax and memorization all over again, but because dangit... i like Warhammer Age of Reckoning and they use a Lua scripting engine to power their user interface.

    So I drug out the notepad++ and tried to muttle around.

    I was frustrated with the 'lack of' build in object orientism, so i explored some more in the documentation

    Here's a little sample of what i put together as a start to 'object oriented' in lua.

     

    --Begin Person.lua

    Person =

    {         

                lastName = "",

                firstName = ""

    }

     

    --constructor   

     function Person:new()

          o = {}

          setmetatable(o, self)

          self.__index = self

         return o

    end

     

    function Person:SetFirstName(firstname)

                self.firstName = firstname

    end

     

    function Person:GetName()

                return (self.firstName .. " " .. self.lastName)

    end

     

    function Person:SetLastName(lastname)

                self.lastName = lastname

    end

     --It's a script so now i'll use the object above in a little test

    local a = Person:new()

    a:SetLastName("Peckham")

    a:SetFirstName("James")

    print(a:GetName())

    print(Person:GetName())

    --end Person.lua

    ------------

    and then i thought, that's nice but what about inheritence and overriding methods?

    so i did this little number

    --Inherited class now with an override in it for GetName
    Male = Person:new()
    function Male:new()
         o = {}
         setmetatable(o, self)
         self.__index = self
         return o
    end

    function Male:GetName()
     return "Mr. "..Person.GetName(self)
    end

    --now run the objects again, note we're using Male now instead of Person

    local a = Male:new()
    a:SetLastName("Peckham")
    a:SetFirstName("James")
    print(a:GetName())
    print(Person:GetName())

    Full story

    Comments (0)

    jpeckham

  • Engineering practices are only as good as the engineers

    9/23/2008 12:28:17 AM

    i'm going to be very frank here.

    Real teamwork is a consensus.

    That's why small teams work best because everyone knows you can't get a consensus with any thing more than about 5 people.

    At times, you'll have the sueaky wheel... but they sueaky for a reason. Listen to what they have to say, apply their concerns to what you're doing. Get them on board. No, don't strong arm them... or muscle them into doing it... but really get at the heart of their issue.

    So teamwork is about consensus and therefore you're only as good as your two weakest links. Face it, if there's one weak link, you can train them up, pair them with someone more knowledgable etc. If there's 2, then that's probably about half your team and you're done at that point because you can't have half your team 'in training'.

    So what Am i trying to say here?

    Well, if you got a couple engineers who absolutely doesn't get polymorphism and inheritance... you can't use that stuff. Why? because they won't understand it then there will be frustration.

    If you got 2 or more engineers who just don't get automated unit testing. Then you can't do it!

    2 or more team members who don't get user stories... don't do them.

    2 or more engineers who don't understand coding standards or write cleanly... you probably can't do "collective code ownership", your better off doing class ownership model.

    Anyhow, you get my drift i hope.

    A wiser man than me said "I get the idea of best practices, but for right now let's just use 'good enough' practices and get on with it"

    Full story

    Comments (0)

    jpeckham

  • Smells that management isn't playing their Scrum Role

    9/14/2008 1:43:24 AM

    as per schwaber, management's role in scrum is fairly simple.

    http://www.controlchaos.com/about/management.php

    So what are some of the smells that management isn't playing an active role in scrum?

    1. Impediments get talked about, but no time is ever set aside to find out what the problem is and who the problem solvers need to be.
    2. Impediments are considered "The individual owner's problem" not the team's and no one cares to help the individual or find out their concern. (Remember everyone has a special background and may be seeing something that others aren't. Explore every impediment and resolve it)
    3. Only impediments that are spoke out loud are considered impediments.
    4. People stop reporting impediments.
    5. People get fidgety on their turn of the scrum meeting. (they have nothing done, have no way to get anything done, but they don't feel like their impediment will get handled so they're afraid to speak about it - a lack of confidence level)
    6. Impediments that are backlogged get removed without being resolved.
    7. Impediments get called "just the way we do things"

    What other smells have you encountered that management has 'checked out'?

    Full story

    Comments (0)

    jpeckham

  • Certified Scrummaster course coming to KC

    9/9/2008 9:23:08 PM

    http://www.scrumalliance.org/courses/2850-certified-scrummaster

    Mike is a great guy to talk to so i'm sure his class will be really good.

    Full story

    Comments (0)

    jpeckham

  • Fail fast!

    9/8/2008 1:06:42 AM

    One of the most important things about teamwork is to commit to the mutual goal and go hard or go home. Sometimes, the team chooses the wrong path. Sometimes, individuals on that team recognize it sooner than others. However, once you've committed, you have to go till the failure is agreed upon.

    I was out camping with some of my girlfriend's family. It started to rain and we had planned to eat at the picnic table that was there. Unfortunately, we'd get very wet eating in the rain. Luckily, someone had a screen tent.

    There were 4 of us who said we'd setup the screen tent and we pulled out all of the pieces and started examining them. No instruction booklet was to be found anywhere.

    We all decided how it was to be put together and started going. About 5minutes in, I noticed something was wrong and tried to mention something. However, the rain was coming down hard, people just wanted to 'get it done' and no one was going to listen to my concerns about the poles being inverted.

    I got frustrated and got out of the rain. I was standing there, dry as the rest of my teammates floundered around trying to put together the tent the wrong way. Eventually, people started giving up and getting frustrated... realizing something was wrong.

    Now, Had i just stayed in the fight and took it all the way to the obvious failure then we would have gotten there faster, then we would have all still been around fixing it the right way... in the end it was just two of us left trying to put it together the right way because the other 2 people got burned out.

    Full story

    Comments (0)

    jpeckham

  • I just want to write code, why do i care about "Done"?

    9/6/2008 7:40:39 PM

    Maybe it's a programmer thing, but we only care about filling the need of the customer. Doing the bare minimum to meet the requirement. We forget about all of the administrative stuff we have to do (until the very end of a project) like : refactored, coding standards, design, documentation,  automated unit tests.

    And we think that because our customer wants it "RIGHT NOW" that we can't possibly spend the time to do these other tasks. They wouldn't have it! there would be another emergency where we have to drop everything and just 'Get it done'.

    We can blame these bad managers all we want but the responsibility lies within us to do the right thing for the code and in the end when we don't... it will be our butts on the chopping block. Believe it!

    So why do we care? Damned if we do, damned if we don't.

    I come from the restaurant business so i really liked this story that i heard one time.

    Let's say i'm in a restaraunt but i'm on my lunch so i don't have much time to eat. I want a steak so when the server comes over i say, give me a steak, i want it well-done, but i'm in a hurry so if you can't get it out to me in 10minutes i'm going to have to leave and pickup fast food on the way home.

    THe server scrambles to the back and rings in a steak then tells the cooks "use magic" to get this steak out. Well 'magic' in the food industry means use the microwave. In fact any time a server screws up an order and needs it out in a hurry... they go to the magic.

    So my steak comes out in 8minutes. I'm ecstatic and i begin to cut into it. O man, i am so disappointed. The steak is so tough my knife barely gets through the rugged microwave hardened gristle. It's so dry i have to soak it in steak sauce. I am angry! I demand they comp my meal for such a disappointment. I leave absolutely no tip on the table and go back to work in disgust.

    The poor waiter curses me for my arrogance because what should that idiot expect wanting a steak well done in 10minutes is absurd! How else was it suppose to get done.

    Frankly, this is how software is a lot of times. The customers want insane things to happen in insane time lines and no one questions them! Their ignorance is compounded by our willingness to appease them.

    Defining done up front of a project or before a sprint ensures that this negotiation happens BEFORE it's too late. before they get a bad steak, let them know that you need to do documentation, training, refactoring, unit testing, regression testing, continuous integration setup, code analysis, code review, security scans.

    Fact is, if you don't discuss it... as soon as the code "looks ready" to them, they won't understand why it's not ready and be pushing to move on to the next thing. And admit it... so will you... because you don't want to do all that administrative crap, you want to write code!

    Think about it... gimme a shout.

    Full story

    Comments (0)

    jpeckham

  • Player pawn pro con

    9/5/2008 1:49:13 AM

    http://www.amazon.com/Managing-Humans-Humorous-Software-Engineering/dp/159059844X/

    I browsed this book at border's the other day... and i have to say it looks very promising but i couldn't afford a book right now so i didn't buy it.

    The author first mentions how we consider managers as evil, but while there are a few that are evil it's easy to tell which ones are by asking a few questions at an interview. My favorite was this one:

     what is your weakness? because if they say they got it all covered then they are either so arrogant to believe they have no faults or they have so many weaknesses they would prefer to hide and really are evil

    THe next thing he talked about that i liked was how to deal with people freaking out in your office. he says never to freak on the freak, but to remain calm and find the 'issue' in their freak and address it. Then also be mindful of the fact that This person believe their only way to reach you is by freaking out. This may be a weakness in your ability to acknowledge and handle roadblocks proactively.

    Then the last piece i read was about about meetings.

    Basically, there's different types of meetings. One is agenda based, and you have a clear goal and when that goal is met the meeting is over. These are easy.

    However there is informational meetings where there are talkers and listeners. If you're not a talker then your job is to listen and understand then get out of there. So don't go asking silly questions that are off topic or derailing the talkers. Sure, feel free to get clarification on the content but stick to the talker's agenda or your just that windbag running the meeting long. (wow , i've been that guy!)

    Then there's con-meetings. Basically, there are cons who have some issue they need addressed so they drag everyone in and are start complaining. "Gosh darn marketing they screwed us up this time". Then there are pros who could solve the problem or are the root of the problem however some might use the tactic of empathizing right along with the cons (bait and switch) "oh yea those marketing guys what a buncha jerks". So this can go on and on and on and just because you hit the time limit doesn't mean it stops because the cons will be scheduling a follow up meeting as soon as they get back to their desk. If this is to be resolved someone (even a pawn) needs to identify the pros who can do something about this and engage them in the meeting to address the issue and resolve it.

    Anyhow, this book looked good and i definitely can learn something from the meeting chapter! :)

    Full story

    Comments (0)

    jpeckham

  • Rad vs Agile ranting

    9/3/2008 4:45:24 AM

    I found this rad vs agile rant interesting.

    http://forums.whirlpool.net.au/forum-replies-archive.cfm/967446.html

     

    Full story

    Comments (0)

    jpeckham

  • Why unit test?

    9/1/2008 9:58:18 PM

    So first, why wouldn't you unit test?

    Let's first assume it's a waste of time because you already have 'testers' who will be testing it for you. So you write some code, assume it's correct, pass it over the wall to a tester and begin working the next item on your list. The next day, after you're deep into the work of this second item the tester finds a defect and writes it up for you and you see it in your email. You can either interrupt the work you're currently doing and go address that bug or you can continue working on the item you're on now until it's ready to be thrown over the wall. Either way you do it, you have to re-engage your brain back to the old tasks of that other feature to verify it's correct.

    here's some other reasons it sucks (With a VERY nice lively conversation in the comments)

    http://www.wilshipley.com/blog/2005/09/unit-testing-is-teh-suck-urr.html

    Finally, here is a good article on why to unit test.

    http://www.agitar.com/solutions/why_unit_testing.html

    I've personally felt more confident in my code once i've written good unit tests. (Right-BICEP - boundaries, inverses/negatives, cross-check, errors,performance) http://www.cs.virginia.edu/~horton/cs494/s05/slides/UnitTesting-lecture-s05.ppt#313,24,Right-BICEP

    I also feel way more confident in the designs I come up with when i do TDD. I actually use things like interfaces to decouple my architecture and think of unique ways to get things into a test harness (which makes it easier to be a client for any of my classes i make when i TDD)

    Your unit tests are only as good as you are at writing them... so if you do not know how to write good tests you will ultimately get no benefit of writing unit tests.

     

    Full story

    Comments (0)

    jpeckham