Global day of code retreat 2013 pt. 2, or “simply TMI”

Was there a retrospective?

Yes. There was a retrospective at the end of the day, and there was conversation in between sessions. The three questions below were asked of each attendee at the end of the day. I personally think that having more retrospecting as part of the event could be beneficial to the goal of maximizing the learning that occurs. I find that I always want to have a longer conversation in between the sessions, but the facilitators often interrupt it – perhaps that’s why they’re the facilitators, because they know better. I’d like to try that each attendee answers all three questions after each session, and then allow for others to tell us what they can think of based on our answers.

What programming languages did you use this year?


To my surprise, I used PHP in all but one session. Previous two years I did not use PHP in any of the sessions I did. This almost certainly contributed to the very low level of frustration I experienced this year compared to previous years. PHP is generally laughed at by programmers who do not program with it, undeservedly in my opinion, so that was also why I was surprised. As for a reason why more people were interested in using PHP, I would be interested in the premise that WordPress deserves the credit. Perhaps I will ask the people I paired with to hear why they chose PHP for our session.

Can I see the code you wrote?


The direction given at code retreat is to delete the code after each session. I prefer to keep it around, so yes, you can see the code here. Though it probably will not be very useful to you.

What activities would do you think would be cool for code retreats?

Each session is often characterized by the “activity” that is being tried out for the session. The facilitators pick an activity that is intended to teach the participants something about creating better software. This is the activity catalog from the official code retreat website.
Through my explorations of software development as it is done by various people, I think the following would be interesting activities:

  • No implementation — all the code written is not taken to the point of actually being executable. This is designed to get people to think about expressive code, how algorithms should be written down in software, while freeing them from having to think about how must I write this in order to get it to “compile.”
  • Procedural code only / No objects — People often think of their use of object-oriented code as something inherently good. Procedural code is often thought of as inferior. I have not learned this yet, even though I’ve been trying to. Another way to say this is the way a famous software developer, Martin Fowler put it: “The OO community may have ‘won’ in the sense that modern languages are dominated by objects, but they are still yet to win in that OO programming is still not widely used.”
  • Outside-in — You have to start at the outermost part of the program instead of starting at some internal part. To understand this, you have to think of what does a finished program, that implements the Game of Life, do. I’ve come to think it accepts an initial ( seed ) pattern, and then returns all the states the game goes through. I think this would be useful to allow people to think of the exhibitable behavior of the program instead of spending all their sessions talking about some internal implementation details.

What did you listen to while writing this post?


I listened to:

You can find both albums on iTunes – Kendrick Lamar, Substantial.

Why did you bring a silver suitcase with a sticker that says “Important” on it?


Because I’ve experienced the benefits of “getting yourself out of your comfort zone” many times.

Sounds like you had a good time. Do you wanna take this opportunity to thank anyone?


Yes! I definitely had fun, I learned a lot, and I am grateful to everyone involved. Specifically,

I would like to thank the sponsors:

I would like to thank the facilitators:

I would like to thank the people I paired up with. I know I am not the most easy going person often, and tend to manipulate conversations without letting others contribute as much as they could:

Is the Yellow Dog Tavern a good place to reflect on a code retreat?

Absolutely.

An OO PHP implementation of a collection of cachable functions

I don’t know about you, but I always get a bit excited when I get to use PHP’s magic methods.

Here’s an implementation I did at work for a class which contains multiple functions whose result needs to only be “calculated” every few minutes, but the results could be retrieved many times by different people within that period ( i.e. the functions are “cachable” ).

See it here.

Winnipeg Code Retreat 2013

Yay!

Code Retreat is coming up again, this time at SkullSpace. Learn more and register to attend!

Here are a couple of links to posts and code I created around last year’s Code Retreat:

Lately, I’ve been programming with Python when I have a choice, so Python and DocTest will be my #1 environment of choice.

I hope to see You, and learn from You there!

Stepwise Refinement, and such

As you may have already heard from me, I feel like I’ve made some significant progress in the quality of the code I am able to produce over the past few months. I haven’t written about it yet, as I’ve been exploring the specific implications and applications of what I’ve stumbled upon.

I’ve had a chance to tell a few new people about it yesterday, and again it’s hard to communicate the kind of benefit that I see potential for, and frankly, it’s hard for a person who has not seen it to believe it. So I’m hoping to be able to communicate to Josh Leuze, author of Meteor Slides, and to Reid and Peter – who, as I understand, both read the source code of The Events Calendar – some of the techniques through the source code of their systems.

Here’s the first example of code that implements some of these principles. I think the refactoring / diff format in which the examples are presented fit well with what I’m trying to communicate, which is basically a collection of changes to how code I commonly read is written. Here it goes:

https://github.com/dbernar1/Meteor-Slides/commit/93cd6b91fc72e8fb8d3413ae366a79af4bcee3c5 is a very good example of where a function is commented to express the functionality. I find it better to just simply name the function using those words – comments very often get out of date.

https://github.com/dbernar1/Meteor-Slides/commit/d80dab8c855a1d918c95d7aec8c64583e44df705 shows using a static variable for a value that is obtained from the database, and doesn’t change during the execution of a program. I like this in part because of use of the uncommon static keyword, in part because it enables removing duplication ( for cases such as when I want to change the option name ), and I find it is a nice way of encapsulating something that needs to get initialized once, like getting a database connection.

https://github.com/dbernar1/Meteor-Slides/commit/35fcb3ac1254bd290a44f4a75b3e8702eac181a9 shows a technique I use to name parameters to functions that take several parameters. Especially nice for naming those “true”/”false” parameters to functions that even the WordPress coding standard suggests trying to avoid. It says: “Since PHP doesn’t support named arguments…”, but I think this example proves otherwise. Of course, python-style named parameters, where order does not matter any more, do not exist in PHP, but it is entirely possible to name parameters to functions as I show there.

https://github.com/dbernar1/Meteor-Slides/commit/7bab45bb35760a7fa5827542a57c556ccbe66ddb is the meatiest example of the bunch. I could have done several smaller refactorings. I suggest reading it by reading the change to meteor-slides-plugin.php first. An important thing to note is that it would have been much easier to express the functionality with well-named function stubs, like the new version does, when originally writing the software. This is because it is easier to express the algorithm of using the overrides if they exist without at the same time having to think about what the implementation of “is this file overridden in the child theme” is. It is also easier to read, because it is in English, not in “WordPress”. It is also important to note how at least one level of implicit meaning has been replaced by explicit meaning, with naming functionality such as “if ( the_child_theme_has_overridden_css_for_meteor_slides() ) {“. I’ll leave you with that for now.

What do you think? I’d love to get feedback from other software developers.