I usually purchase technical books in paper form. It might seem silly being a geek and all, but paper copies provide one thing electronic copies have not yet caught up on: lendability. In my so-called circle I lend books I recommend to people. That gives them a shot to look through the book and figure out if my recommendation is warrented and then (hopefully) purchase their own copy and return mine. It doesn’t always work out that way, but that’s the idea.
If I thought it a good idea, I would let you borrow these books in order. But I only have one copy of each and I think you can probably find a copy at a library, in a friend’s collection, or for a reasonable price on Amazon.com, so I’ll just stick with a list.
The progression of books I tend to recommend to people wanting to appreciate JavaScript is as follows.
This book covers the basics. You’ve probably seen the classic Good Parts vs Definitive guide photo but that is only part of the story. The Good Parts covers the basics of syntax, objects, regexes, methods, inheritance, and a little style all in one tiny package. Reading this book will not make you proficient in JavaScript, but it should lead you to the questions you need to ask about the language. The idea is to get you thinking about these subjects and allow you to discover the areas you need more explanation. That is why I suggest this as a first text.
One word of caution or a caveat–Douglas Crockford has many opinions about the langauage and style in particular. While they are usually rooted in logical analysis of his experiences with JavaScript, they aren’t always shared by every JavaScript developer. Don’t get caught up in Crockfordian Vs. Everyone-else-ian JavaScript at this point. There will be plenty of time to argue and bicker later. Digest what is being offered and find the areas you need further explanation.
View JavaScript: The Good Parts on Amazon.com
Patterns are important in any language, and we aren’t just talking about design patterns here. I’m talking about development patterns and practices to create modular, extensible, reusable, and all the other important *-ables. In this book you will find extensive explanation of useful habits and patterns for writing JavaScript that is a pleasure to maintain. This is the goal of any developer, or at least it should be. The book will get you started on writing such code in JS.
As a companion resource, there is an excellent collection of pattern explanations and examples by Addy Osmani called Learning JavaScript Design Patterns. Bookmark this ebook and reference it as you use the patterns. It is helpful even after you grasp the concepts well.
View JavaScript Patterns on Amazon.com
This book, in many ways, is a rehash of the first two books. So why would I recommend you read it? To learn the subject from a different perspective, that’s why. Having different voices and different backgrounds is essential to having a well-rounded knowledgebase on any subject. I recommend this book as your third text so that the insight you picked up in the first two is hopefully fresh and you will be able to whizz through this book picking up the subject in a slightly different light.
View Eloquent JavaScript on Amazon.com
When do you worry about optimization? While you’re first learning how to solve a problem? No. So I recommend a book about performance and optimization after you’ve grasped the basics and patterns of writing JavaScript code. This book has great examples and tips. One word of caution, if you are familiar with concatenation, minification, and such practices you might find some of the book to be a bit basic. However I still suggest you read through it as it does offer some insight you might not otherwise pick up on.
View High Performance on Amazon.com
I recommend these books in this order because they helped me learn about the language. There are many other options and many books and resources which follow these, but if you are looking for books to get you prepared to be enthusiastic about JavaScript, these should do the trick.
Assess your knowledge level and pick up the list where you think you should. However, for the most well-rounded view of the language I think everyone should read all of these books at least once.
]]>You might be thinking, but ZendCon is a PHP conference, what is the relevance of a JavaScript talk there? Simply put the idea of a purely PHP developer–when talking about the web–is rare these days. Hybrid and generalist programming, or polyglots if you want to be a hipster, is the type of developer you want to be. Don’t just trust me, trust many other developers much smarter than me. (Seriously, Google it.)
So, I sent in this proposal and it was selected. I was then tasked with figuring out a coherent progression from PHP mindset to a modern-day JavaScript developer. This was no easy task, and I still don’t think I got it 100% correct.
I gave this talk on Wednesday morning at 11:00AM. Imagine my surprise when the room was mostly full by 10:45. By 10:50 there were no seats left. One of the ZendCon staff kindly retrieved more chairs to give the people congregating in the back of the room a place to sit. Those chairs filled and yet still more people showed up. It would be easy for me to take this as an ego boost, but I recognize the people weren’t there to hear me, they were there to hear about JavaScript.
The session (slides below) started out with the basics of JavaScript including arrays and objects with emphasis on the translation of concepts from PHP. I spent a considerable amount of time on the idea of “almost everything in JS is an object” and on the Constructor Function pattern because it is important for OOP-minded PHP developers to understand how to construct similar “objects” in JS.
I then moved on to organizational patterns including how to namespace code and the famous–or infamous, as it were–JavaScript Module Pattern. After the talk I received several comments from attendees about the module pattern and how it will help them organize code better. That was the point, so I’m glad it came across in tact.
Then came the porition I wasn’t sure on, but knew I should include: tools for development. I picked several tools and frameworks that I have personally used to highlight the transition from similar tools in the PHP ecosystem. These are require.js, Backbone.js, QUnit, and GRUNT. These translate to autoloading, MVC-ish frameworks/libraries, unit testing, and build tools in PHP.
After this talk, several people approached me over the next day and a half to discuss the ideas I presented further. There is literally nothing that could have been more flattering than to have inspired conversation and questions in attendees. Don’t get me wrong, five stars on joind.in is great, but knowing a session I gave led someone to improve his or her development skills is much better.
I did not get the amount of feedback I hoped for on joind.in. ZendCon has paper evaluation forms and doesn’t push joind.in ratings as a conference, so it’s up to the speakers to encourage–or beg–attendees to take a few moments to comment electronically. I clearly need to work on my pitch.
However, the comments I did receive are overwhelmingly positive, but shed some light on one critical shortfall of this particular presentation: the breadth of the information. Since I took attendees from basics to tools, there is quite a bit to digest. Part of this is intentional, as the subject of JavaScript for PHP developers is quite vast, but if I give this talk again I’ll likely try to split on JavaScript (the langauge) for PHP developers, and translating PHP development practices to JavaScript. This will make it easier for attendees to digest the material, I think.
If you were able to attend and haven’t had the opportunity to rate and comment on joind.in, please take a few moments to do so now. I will greatly appreciate any comments you have to offer.
If you were not able to attend, hopefully the slides are content-rich enough to provide some value to you and this post of my thoughts leads you to some JavaScript enlightenment.
I’m going to follow this up at some point with a post on books to read, but to get the gist of the material I suggest checking out JavaScript Patterns by Stoyan Stefanov and Eloquent JavaScript by Marijn Haverbeke. These two books are essential reading for anyone looking to understand patterns in JavaScript. Additionally there is an e-book, Learning JavaScript Design Patterns by Addy Osmani which is a great resource to have bookmarked as you explore development practices in JS.
]]>Zend Framework 2 was clearly–and rightfully–a theme found in many of the sessions at ZendCon this year. One of the coolest parts, in my opinion, the team has been working on is providing infrastructure and patterns for creating real modules to be consumed by ZF2 applications. Evan Coury said it best in one of his sessions by mentioning that he worked on modules for ZF2 because ZF1 “supported” modules in theory but in practice the implementation was not widely used and had some signficiant design flaws. Take a look at the slides and video from his session, “Introduction to Modules in Zend Framework 2.0.”
The other major take away from the ZF2 and related talks is the idea of components. If you’re like me, you remember ZF1 being billed as an at-will framework, meaning you can use any of the framework components, e.g., Zend_Db, the MVC implementeation, etc., at will without having to use the rest of the stack. This is a powerful concept and is something the team has made even easier in version 2.0. The power of this concept became abundantly clear with sessions such as the joint presentation given by Stefan Koopmanschap and Enrico Zimuel titled “Zend Framework 2 and Symfony2: The Perfect Team” and Ryan Weaver’s presentation “Easily Integrate Zend Framework 2 and Other Libraries Using Composer.”
Take a look at the components ZF2 and Symfony2 offer. I have a feeling you might be able to use at least one in your project today. If this isn’t inspiration to get out and experiment I don’t know what is.
(Full disclosure: one of my sessions was on testing, specifically mocks and fixtures within unit and integration tests. It’s a subject I am passionate about.)
It is encouraging to see emphasis on development practices such as testing and profiling at a conference such as ZendCon. While it occasionally seems like a repetative subject, if the focus is on better techniques for each as opposed to reasons why I think these sessions are still valuable.
In addition to my session on using mocking frameworks and fixtures in tests, the creator of PHPUnit, Sebastian Bergmann, presented a session on “PHPUnit Best Practices” as well as a session on “Living With Legacy.” Both of these sessions provide insight into writing better tests as well as the common situation of writing tests for legacy PHP applications.
If you do not know how your code performs, and even if you have an idea, profiling is an invaluable tool in tweaking code for better experience as well as finding bugs that you might not otherwise be able to gain insight into. The author and maintainer of XDebug, Derick Rethans, presented “Profiling PHP Applications” which covers this exact topic using the XDebug library. His realistic examples make the concept much easier to digest than simple documentation ever can.
Ilia Alshanetsky presented “Bottleneck Analyis” which took attendees through possible application bottlenecks from the outside in. It is important as web application developers to remember that the code is only one portion of the delivery from the server to the client and having the tools to examine each of these layers is critical to creating a responsive or performant application.
The hallway track is one of the most important benefits of attending a conference. Personally speaking, I had many great conversations outside of the presentation rooms. At one point I had a 30-minute discussion with an attendee about the idea of transferring applications from mainframe to web and the requisite paradigm shifts and approaches to improving the interface with code.
I also spent considerable time talking with several people about deployment and systems architecture approaches. While this isn’t a direct responsibility of mine, I have spent a considerable amount of time in this arena–yes like a circus if I’m doing it–and having more experienced people to bounce ideas off of and learn from their approaches is invaluable. I already have several areas I want to improve based solely on a 15-minute conversation next to an escalator. You can’t put a price on that.
As usual the ZendCon UnCon was top notch. Michelangelo van Dam did another impressive job organizing and running the uncon, as well as contributing. I attended his UnCon session on the benefits of community titled “Community Works!” I mentioned this in my comments on joind.in, but if you did not get a chance to hear this session–and I know you did not since I was the only one in the audience–you missed out greatly. Even if you are already engaged in the community it was inspirational to say the least.
There was a much tweeted and successful uncon session by Lorna Jane Mitchell titled “Git + Github: everything you need to know!” I did not attend this session, but from the buzz on Twitter and in the hallways I would say it has inspired and opened doors for many attendees.
I am a much better developer for having attended ZendCon 2012. I was proud to be a part of the conversation with my two sessions (which I’ll write about in another post) and as an attendee. If you were unable to attend this year I hope these insights provide some value and I urge you to start planning for next year. I dont expect ZendCon 2013 to be anything less than purely awesome.
To the Zend team, the ZF2 team, the team at S&S Media, the exhibitors, the sponsors, the speakers, and most importantly the attendees, I thank you all for the memories. I hope to catch up with you soon.
]]>We are putting on the next edition of the conference–it will take place on February 2, 2013–and I am pleased to announce the Call for Proposals is now open for your submissions. This year we have several speakers that are already committed to speak at the event and we have saved slots for you to speak. We want to hear from the community so this is your chance.
Submissions will be accepted starting today and running through October 28, 2012 at 11:59:59 p.m. Submit as many proposals as you’d like. We have reserved slots for full sessions (50 minutes in length) and are introducing a new format this year composed of three 10-minute talks back to back. This is a play on “lightning talks” and is aimed to give new presenters an opportunity to give a less stressful session on a more focused topic. However, if you’re an experienced speaker with a great idea for a 10-minute talk, please submit one.
Along the lines of wanting to encourage new presenters, this year we want to offer a sort-of mentorship opportunity. Members of the HTML5.tx organizer team have volunteered to help mentor any speaker that might wish to speak at the event but needs a little help developing his or her topic or slides. We will be available for questions or to review anything you might need help with. Please don’t let fear keep you from submitting a proposal.
I can’t wait to see what you want to talk about. Submit today at http://bit.ly/cfp-2013.
]]>Before I get into my thoughts on the presentation, I wanted to make a quick comment on the makeup of the conference itself. This was my first time speaking at a conference that wasn’t focused on the technology stack I use on a daily basis. Basically, ThatConference was not a PHP, JavaScript, or web technology conference, it was a summer camp for people that hack on things or just have good advice for geeks. I would say that the majority of my interactions were with developers in the .NET space–and there were a few people that gave me a condescending glance when they figured out I use PHP–but, for the most part, the judgement was low and we all found a benefit from our conversations.
My session, while specifically addressing tools for PHP, was geared toward how to approach a message codebase without sacrificing sanity of having and introducing tests. I had some good questions that I will incorporate into this presentation if I ever give it again, and a few conversations afterward that encouraged me that the PHP community is starting to accept testing as a so-called first-class citizen.
My presentation is available on SpeakerDeck. If you were there and have further questions, I look forward to hearing from you. If you’re reading the slides for the first time and have questions, I’ll be glad to answer anything I can.
I had a blast at ThatConference 2012 and look forward to heading back to the MidWest next year for ThatConference 2013. If you are a fan of bacon, you might want to check it out. There was a bacon bar. No, really.
]]>Small footprint libraries and so-called micro frameworks are a newer development in the PHP community. In this session we’ll look at the MicroPHP Manifesto and go over building an application focused on the ideas presented by it. We’ll look at a couple micro frameworks and other tools including Slim and Breeze as well as concerns with implementing your frontend with Backbone.js and other techniques. We’ll also cover simple ways to organize your application and manage dependencies using Composer.
And the slides are available on speakerdeck.com.
The first thing to address is with the abstract itself. Looking at two micro frameworks in the code and demo portion of the talk was well simply too much content to present in a single 50-minute session. That is 100% my mistake.
Other aspects that were difficult to address within the time limits are fully addressing Composer and code organization. I was able to push code organization tips into the sample code I provide on Github. My original intent was to introduce Composer as a tool to help expose and make it easier to use MicroPHP libraries and frameworks, but I can see that the abstract, as written, makes it seem like I will provide more in-depth information about Composer.
The slides themselves are a resource. They contain highlighted code that can be used to find the important bits in the example code found on Github.
This brings me to the areas of the talk I need to address should I ever give this session again.
A 50-minute session is supposed to be used to inspire the attendees to take a pointer from the talk and go out and research and experiment with the concept. It simply is not feasible to truly teach someone even the basics of a topic in just 50-minutes. The very first comment I recieved via joind.in told me I did not convey the message I wished to through this session. The author said, “I am not sure I understood why one would use a micro framework for the PHP side, but a full framework for the JavaScript side.” Ignoring that Backbone.js is most assuredly not a “full framework” by any stretch of the imagination, he has a point. It’s not that I should not present the concept of using microphp frameworks to expose APIs for a JavaScript frontend to consume, it’s that I failed to make it clear that I was not advocating you pick up a single micro framework and solely use it for your entire backend. That is completely not the message I intended to convey.
To clear it up, my point was to use Slim as a way to expose a RESTful API using existing components of an application to handle business logic, etc. The example I use feels too much like a contrived example, and it shows through this comment. That must be cleaned up.
Orginally I hoped the introductory material on where MicroPHP stands, and some commentary on the manifesto itself, would help steer the focus of the audience to treating Slim less like a replacement for Symfony2, Zend Framework, Kohana, etc., to looking at Slim as a small-footprint library that solves a signgle problem: HTTP request routing. Unfortunately, given the time constraint, I was able to spend enough time on neither the subject of why you would consider MicroPHP nor actually using micro components. That should be addressed by splitting this session into two talks. One more of a soft talk on the concepts. The other a technical introduction to using a collection of libraries.
One other comment from joind.in makes it painfully obvious that something I said was not crystal clear. Here it is.
Not very convincing that Slim or MicroPHP is ready for prime-time use, since you said you had to build extensions onto Slim in order to return JSON…
The author of the comment is referencing a Middleware component for Slim I had to write to deal with content negotiation. This was a very specific implementation decision I made to be more of a REST snob. The author of Slim is working on a much better implementation of looking at the Accept request header to determine what type of payload the client expects to recieve. Since it is under development, I do not see the reason to spend much time on implementing a middleware component for slim that does the same thing. This was, again, a decision I made to support the Accept header instead of the ugly hack of appending “.json” to the URL.
If we are using a framework’s support of automatically returning JSON-encoded data based on the Accept request header to determine whether that framework should be used in a production setting, we are dooming any site or application written on top of the Zend Framework version 1.x, since this isn’t a feature in the core framework. Personally, I think that is a bit rash.
The result of not being clear is this person has a jaded view of MicroPHP libraries and frameworks. I have failed the community.
For the first time I presented this topic, which I know is one that is hard to stomach for many devs anyway, I think it was a success. It just needs a little tweaking. I hope my commentary here is useful.
]]>I know I’m not alone in this. Getting up in front of a bunch of one’s peers to talk about something technical is difficult. I am confident that even those that routinely present will say the same. The best advice I’ve ever received about presenting is: recognize that you might not be the most knowledgeable person on the subject in room, that you do not know the answers to every question, and that the only thing setting you apart from the audience is your name badge. It’s true. This is precisely why it’s so important to give feedback to the person that spent many hours crafting an idea into slides and words–no small feat.
It is easy to sit here and say, go give valuable feedback to people. I myself sometimes have a hard time with this task. But I think a small set of questions can help you figure out what to say:
I guarantee you answering any or all of these questions will definitely be appreciated by the speaker presenting at the next event you attend. There are many more that you can answer, but I think you probably get the point by now.
The takeaway here is you should take a few moments to rate your speaker, but it’s more important that you give him or her advice on how to improve the talk next time. Doing that will make your input much more valuable that just saying, “meh - 2 stars.”
]]>The talk is focused around the idea of using MicroPHP to create an application that has a main view layer written in JavaScript. For implementation specifics, I will focus on using the Slim PHP Microframework with a Backbone.js frontend. I hope to see you there!
For what it’s worth, I looked at the rest of the speaker announcements on Twitter, and it’s a kick ass lineup. You won’t want to miss this conference.
I had to miss LoneStarPHP last year due to other commitments, but I hear it was a great success. And this year it’s expanded from one day to two days. If you’re in the area, come. Just do it. It’s a good investment. The PHP community rocks.
]]>The very first question I get when I tell people about my new position is, “What is Liftopia?” The short answer is it’s an e-commerce platform that allows ski resorts to move lift ticket inventory at discounted rates. The long answer is much more involved than that, but since my blog leans to the more technical side of discussions, I’ll leave it at that.
In the Liftopia ecosystem I work on Team Dev–hopefully that is not a surprise. We maintain, add to, and fight fires with the infrastructure that our website, mobile site, mobile applications, and growing collection of cloud–DRINK!–stores sit on top of. We code in PHP and JavaScript, talk with MySQL and MongoDB databases, and serve up traffic through Apache and Nginx. My specific role on the team is general web development including patching bugs, implementing features, and even the occasional delve into systems administration.
Higher education is an interesting place to work. It really does exist as its own ecosystem and culture. I noticed this during my four years working at Texas A&M University. I also noticed that like any large company there is an immensely rigid corporate structure and everything has a form that must be filled out. For some people this structure is liberating. For me it was prison. I’m not saying that I loathed my time at the University. In fact, I met some really great people and had a lot of fun working with them to accomplish the goals of the Texas A&M community. It’s just at this time I needed something with a little less red tape and a little more excitement.
Another major contributer to my decision to accept this new position is my personal life. My wife and I are expecting our first child in June 2012, and the flexibility provided me by my new position will be a major asset as we raise him. Telecommuting is interesting in that, when you tell non-telecommuters that you work from home and are expecting a baby, the first reaction is, “oh, that’s great! You can stay home and watch the baby!” While that would be rather fantastic, I do have a job to do and I’m fairly certain I don’t get paid to watch my own child. That said, I know that my current role will offer me more opportunities to spend time with my child than working a traditional office job.
So that’s it. I have a new job that I’m excited about. If you are going skiing or snowboarding, you owe it to yourself to see if the area you want to go to has any deals listed on our site. (No, I don’t have any insider information or massive amounts of credits I can give you.)
]]>One such question is, “how can I write perfect code?” Some readers will laugh at the notion, others will think of their favorite techniques and acronyms such as DRY, SOLID, or even YAGNI and consider those to be a measure of some level of perfection. Neither group is wrong.
The problem isn’t with software developers, it isn’t with clients or customers, nor is it with anyone else. The question is flawed. The question assumes there is a state of code that will be impervious to any situation thrown at it. While some of the greatest minds in software engineering are attacking problems in process to aid developers in dealing with a wide array of changes, problems, and situations, writing code that will be perfect is impossible.
Now that we’ve gotten past the idea that we can ever truly achieve flawless software I’d like to take on the task of defining my thoughts on chasing perfect software.
I treat code quality a bit like normalizing a relational schema. There are “perfect forms” of software increasing in complexity and stability, but there is also the possibility that deperfecting–you know, like denormalizing–is the correct action to take for your software project.
The first level of perfect software is a functional piece of software. Funtional software accomplishes its goal consistently. If we’re talking about some e-commerce platform, the ideal piece of software would allow store owners, managers, or administrators to enter products, prices, and inventory into a system and then allow customers to purchase those products. But to be considered the first level of perfect, the software must do with very little error.
In an ideal world, the error margin would be 0%. However, there will be issues, so I still consider the software first level of perfect if it performs as intended 95% of the time based on wholly unscientific calculations.
This definition of perfect is incomplete because it favors the happy case, meaning it only takes into account ideal input and conditions.
To get to the next level of perfection, software must validate data and expectations and filter data as necessary. When talking about validation I favor extreme paranoia. Always assume the input you have is not only completely wrong, but possibly maliciously wrong.
Personally, I think the term input validation is a bit misguiding. Input doesn’t solely refer to data coming from your UI, it’s data coming from any source other than the method or function working with the data. That means you need to be sure the data coming from your UI is fine; the data coming out of your database is as expected; the data coming from a webservice is valid. Trust no data source.
This is a big part of making great software. However, when I say testable software I could be talking about any number of levels of testability and any type of tests. Specifically, I am speaking about unit testing.
Whatever your feelings towards unit tests might be, writing code that is testable will greatly improve the quality of the project. I dare say that such a practice will improve a project even if not a single test is written. I do not advocate this practice, however.
You might ask, “what makes code testable?” That’s a great question. I’ve blabbered on and on about the idea of testable code in the December 2009 issue of php|architect, and more recently my friend Chris Hartjes published a book on the subject of testable code entitled, “The Grumpy Programmer’s Guide To Buliding Testable Applications In PHP”. It’s well worth the investment if this is a topic of interest to you.
Oh documentation. The bane of many a software developer’s existence. It’s a difficult area for many because we’re taught silly things about writing documentation and then we get frustrated with the utter uselessness of most documentation. The important thing to take away is that your code should have documentation to help you or whomever gets the pleasure of maintaining the project in the future.
Good documentation should show the reader how to use the code being documented to accomplish a goal. With any sort of luck the goal will be apparent by the name of the code block, function, etc. being documented, but in the real world that isn’t always the case.
You can start with phpDocumentor, but my absolute favorite documentation is unit tests. If a test suite is grown over time with each bugfix, edge case, etc., the unit tests should tell me a lot about how the code is intended to be used. This doesn’t mean I won’t change the intention, but I have a good idea at the outset what I should and should not expect.
In an ideal world, all the levels above will be completed for every piece of software out there. But at the end of the day, the most perfect software solution to any given project is the software that you have written, provided it accomplishes the goal.
This isn’t my way of saying, don’t strive for excellence. It’s my way of saying software must constantly evolve, but you should realize that the pursuit of perfection is a long journey. Release what works then fix the blemishes.
]]>I responded that I found what I consider to be a good use case for certain magic functionality in PHP. At the end of the conversation, Joshua agreed that the so-called magic functions can be used for good but it is often wielded inappropriately which leads to frustrations such as what inspired his tweet above.
PHP has a magic metho named call(). If you aren’t familiar, call() provides method overloading functionality for PHP classes/objects. This is often used for implementing proxy functionality among other things but I thought it might be useful for deprecating methods after extracting their feature from a class.
In this situation we had a classic case of a class that does more than one thing and an obvious need to extract the second class. When working on the refactoring we have two choices: 1) we can remove the methods and find/replace all calls to those functions from any client code, or 2) leave the methods exposed and available to the client code, but implement the new refactored class inside these methods. I propose that we can use the __call() method to continue to provide/expose these methods while allowing time to fully deprecate and remove the methods.
class PersonMapper
{
public function find($id)
{
//do something related to people
}
//...snip...
public function __call($method, $args)
{
if (false === stripos($method, 'building')) {
throw new Exception('Unknown method ' . $method);
}
trigger_error(
'Using deprecated method ' . $method . ' on object of ' . __CLASS__,
E_USER_DEPRECATED //NOTE: PHP 5.3.0+ required
);
$newObj = new Foo();
call_user_func_array(array($newObj, $method), $args);
}
}
As you can see in the __call() method, I first check to see if the called method matches the criteria for the deprecated methods. If it does we trigger a warning (to show up in development logs) and then call the method on an instance of the new class.
Magic for good and no Harry Potter involved.
]]>Disclaimer: this is my first time being a conference “organizer,” so do forgive me if my observations elicit a hearty “okay, noob, everyone knows that!” from you.
One of my absolute favorite things about HTML5.tx is it truly sprang from a simple comment, but it took off and we are really doing this. After a presentation about the current state of HTML5, Brandon Satrom mentioned on Twitter that he was “actually toying with putting on a full-day HTML5 event in Austin (w/ svrl speakers).” He went on to ask if my fellow B/CS community organizer Robert Stackhouse and I thought that folks from B/CS would make the trip out to Austin. We did. From that, the public Google Group for HTML5.tx was born.
Over the next few months, people stepped up and owned tasks. We shared our talents, ideas, and time, and we have a great lineup of speakers to share their knowledge. It all started with a Tweet. To me that’s amazing.
Originally, I was a bit reserved about taking part in organizing this event. I’ve never done this sort of thing before, and I wasn’t sure I had the contacts or abilities to make a difference in the event. I learned that it doesn’t matter. I have skills and so do you. You are a valuable part of your community and whatever you are able to contribute will be welcomed. Just step up and get it done.
For my part, I volunteered to wrangle speakers. I did not do it alone by any means, but I like to think that my contributions to the lineup haven’t gone unnoticed. In the process I learned that there are some really smart people who are very passionate about what they do who are willing to share it with complete strangers just because. Okay, I didn’t really learn that, per say, but it was reinforced. If I hadn’t stepped in to work on the speakers team, I would have missed this insight.
(Well, at least for the type of audience that will attend HTML5.tx.)
As far as I know, our primary method of marketing was and is Twitter. We have a Twitter account for the conference itself, and it is heavily retweeted by my fellow organizers and, in turn, their thoughts on the conference are retweeted by the conference account. How do I know it works? We got some awesome proposals in our call for papers, which we announced on Twitter. The conference sold out last week. Yep, marketed on Twitter. It was the perfect outlet for this type of event.
If you’re coming to HTML5.tx, I can’t wait to meet you. Say hi! If you didn’t get a chance to pick up a ticket before we sold out, we are recording the sessions. I’m proud to be a part of this conference!
]]>I’ve found it’s important to keep a clean, organized workspace. When I say that, I’m talking mostly about your physical work area; usually a desk or a table. If you’re a coffee shop surfer, you likely don’t have the opportunity to clutter up your desk, but it’s equally important to organize your travelbag.
That said, I’m going to talk about your virtual workspace instead of your physical one.
Your virtual workspace is one area that I disagree with the general statement that “less is more.” I don’t suggest a wonton usage of workspaces, but, in my experience, having a separate desktop or workspace for each category of tasks has significantly increased the volume of work I can accomplish. I am, of course, speaking of the “Spaces” feature of Mac OS X and the virtual desktops in Linux windows managers. I don’t have enough experience with Windows to suggest a tool to add this functionality, but a quick Google search turned up a few suggestions.
In my case, I typically use four distinct workspaces. Like I mentioned, I split my workspaces up by task. My first workspace is my coding space. I typically have an instance or Vim open (GVim or MacVim) and usually a terminal to interface with data providers or whatever, and a web browser. The web browser is the only thing that crosses spaces, but that’s just a reality Ihave to live with.
My second space is where I push my systems administration tasks to. Typically this means I have a terminal open (tmux FTW!) connected to several machines. It’s such a party sometimes.
I push all my distractions to my third space. I classify distractions as my email client, my Jabber/IM client, my Twitter client, and other so-called social outlets accessed via web browser–such as Reddit, Google Reader, et cetera. It takes some getting used to, but it’s completely within the realm of possibility to only access this workspace during planned times for interruptions. I’ll admit it does put a damper on the meaning of instant messaging, and it’s virtually impossible to keep up in IRC, but it’s necessary for optimal efficiency.
My final space is reserved for “incidental usage.” This can be anything from mockups, to reading materials specific to the project I’m working on, so on and so forth. I try to avoid needing this space, but sometimes it’s necessary.
A major time sink is processing incoming communications and file resources. I won’t classify myself as an expert at organization, task management, or the like, but, borrowing from several methodologies, I have come up with a system that works for me.
Following the “inbox” concept prevalent in email systems as well as the Getting Things Done methodology, I have a set of easily-accessed directories that I dump files into when they need work. I also have a mirror of this setup in my email systems. I label my directories with numeric prefixes (for sorting purposes.) I’ll admit it’s ugly, but it works for me. Here are the directories:
I use these directories to store files I’ll need to complete my tasks, and then in the archive I have files I need to keep for whatever reason. The first set of directories corresponds to task planning. Usually I’ll have an email or two in a similarly-named folder and I work on my schedule in my editor—more onthat later. The 20-projects directory is for current projects. Once a project is complete (or out of my current scope) I move it to the 99-archive directory.
From the names, you should be able to gather how things are organized. It’s a sort of divide and conquer technique for file management. I haven’t lost a file yet, and these directories are synced with an online backup as well as to portable storage on a weekly basis. It Just Works.
I mentioned in the previous section that I schedule tasks in my editor. I subscribe to using the Pomodoro technique. If you are unaware, this technique revolves around scheduling things in “Pomodoros” which are 25-minute work iterations. After each pomodoro, a 5-minute break is taken with every 4th break being 15 minutes. It sounds complicated, but it truly is stupid simple. I use http://tomato-timer.com to handle the timing. It’s free and very portable. If you want more information, I highly recommend this book from the Pragmatic Bookshelf for an overview of the technique.
I manage my activity inventory—a fancy term for a running to-do list—in Vimwiki which syncs through an online data storage provider. This allows me to access my inventory from every machine I use. Thanks to some awesome individuals (Travis Swicegood and Matthew Weier O’Phinney) I’ve managed to integrate vim-task with Vimwiki and I have a clean way of managing task lists. Vimwiki also allows me to create a “today” page in my wiki, where I place my task list for the day and assign pomodoros.
The one issue I haven’t solved is a quick way to carry my activity inventory with me. Right now I’m using Remember The Milk and Evernote from my phone, or just plan old fashioned notebook and pen. But this is cumbersome and I’d like to find a way to directly inject my tasks into my synced list. I could possibly accomplish this by syncing my phone to an online provider and manually editing the text file for Vimwiki, but I’m not sure I like that.
The last thing on my list is an issue tracker. It’s integrated into my workflow, but not necessarily my other tools. This is an area I’m exploring. If you have tips, please let me know.
Productivity is something you can teach yourself in less than a week. These techniques work for me, but they aren’t an end all be all solution. I’m constantly evolving my techniques and tools, I just hope my trials can help you.
]]>Note: I’m not knocking on PyTexas at all. It was organized well and the sessions I attended were informative. However, in talking with a couple attendees and presenters I noticed something that hadn’t dawned on me before, and is particularly relevant as I am helping organize a conference schedule and also hope to present at more conferences in the future. (Shameless plug to both HTML5.tx and ZendCon2011.)
The one thing missing from this conference was the intermediate level. There were talks and activities aimed at pure beginners as well as sessions that were clearly for advanced developers. I think that is great. But, in my case in particular, what I needed was something in between.
I attended talks in each of the available levels, and my suspicions were confirmed: the beginner talks were too below my abilities, and the advanced talks had content that won’t fully grasp for a few weeks of working with Python. You might wonder what an intermediate-level session might look like. Well, me too. I have some ideas though.
Coming this conference as a (mostly) PHP developer, there were obviously some differences in language features, but, more importantly, there was a language barrier in terms of definitions of features. I heard a lot about “decorators”—which, incindentally are a really awesome feature—but I had to spend significant energy figuring out what a “Python decorator” was, which left me behind in most of the advanced talks that glossed over them.
One particular talk idea would be, as a general concept, Python development lingo. This would obviously require someone that has enough knowledge of other languages to point out examples if there are any. On a more specific level, Python for PHP/JAVA/C++/Ruby developers talks—open space idea rightthere—would be great.
Another idea for such an intermediate session would be focusing on particular programming paradigms. For example, Object-Oriented Programming in Pythonwould fit in this category. A talk of this persuasion would allow me to use my previous knowledge of programming with a concrete parallel into Python.
Anyway, that’s my little “lightning post” on what I’d love to see at language-specific conferences. It would make them more accessible to those wanting to learn who are not total beginners to programming in general.
]]>Web developers. Mobile developers. Designers. Professionals. Amateurs. Students. Your cat or dog. Okay, maybe not your pets, but we’re trying to put together a groups of speakers that can show us the ins and outs of using HTML5 and related technologies right now. Yes, you read correctly. We’re talking about cool things you can hear about on October 8 and implement in your projects the very next day. (Or, if you’re truly inspired, head over to the open spaces and hack away with your fellow attendees.)
Well, that’s kind of up to you, isn’t it? Ultimately the team of organizers will pick the final lineup, but we’re trying to be as transparent as possible in creating this conference (just check out the public Googlegroup) and we’re truly listening to what you have to say about the proposals submitted to our Call for Papers. Go vote now!
We discussed ways to deliver two tracks of talks. The first, and most obvious, separation is design and development, but we think that’s played out. We wanted something fresh. We came up with having a “new” and an “improved” track. We’ll look for talks that show us new features and new ways of doing things made possible by HTML5 for the “new” track, and we’ll focus on ways HTML5 improves design, development, and even the end-user’s experience in the “improved” track.
For best results, I suggest you attend a couple of each track.
Also, it’s not too late to get your submissions in. The CfP closes on August 19th. Submit what you’re passionate about.Please?
October 8. We’ll possibly have a pre-event event, and likely a post-event event, but the event is on the 8th. If you have to pick just one day, be thereon the 8th.
Come to Austin. It’s a great city. You won’t have time for touristy things, but come immerse yourself in the glory of HTML5 at the Ragsdale Center of St.Edward’s University. You can check out the tourist spots on Sunday.
You’ll meet some really cool people with some awesome ideas and intensetechnical knowledge. You’ll get a free t-shirt. (We are apparently advising you not to wear it at the event; I’m not sure you want to be “thatguy.”) But most importantly you’ll gain some knowledge that you can use tomake your projects better. You can’t put a price on that, but we can! It’sonly $79, though. A small investment and a great value, but I might bebiased.
I’m glad you asked. Get your ticket from EventBrite.com.
]]>To me, professionalism is a choice made each time a decision is required. Knowing when to say no and when to say yes is a hard choice. Uncle Bob stresses that as professionals we must be able to recognize how to decide whether we can commit to a task or if the task is beyond our capabilities. That’s always been a sticking point for me, and I know I must work on it.
I can’t wait to get through the rest of The Clean Coder. It and The Pragmatic Programmer are on the list of required reading for current and future developers.
]]><tab> key was mapped correctly. But I could not get the snippets towork.
After symbolically linking the files into the root of my .vim directory, snipMate worked like a champ. It blew my mind, I just wanted it to work.
Then I figured it out. Part of one of the blogs I followed had me add letg:snippets_dir = $HOME . "/.vim/snippets" to my .vimrc file. The issue I was having was staring me in the face. Before I symbolically linked the snippets directory into my .vim directory, snipMate couldn’t find any snippet definitions to use, so it obviously wouldn’t work.
My solution is to instead add .vim/snippets to the rtp. Works like a champ. I now have the default snippets and my custom snippets.
let rtp += $HOME . "/.vim/snippets"
I found the answer on Twitter of all places. Ed Finkler(@funkatron) touched on the idea when he tweeted, “Thinking about how to “reboot” PHP package management using existing tools in a non-framework/app-centric way. Make PHP hacking fun again.”
That is the answer. The fun of not knowing the solution, or even of creating a solution without the context of years of experience. It’s gone. Or is it?
Several years ago I went from rolling my own MVC architecture to falling in love with the implementation found within the Zend Framework. (Regardless of your opinion of the ZF, there is some library that you find yourself using practically everywhere, so just replace ZF with that library’s name.) As a result, I find myself thinking of solutions in the “Zend Framework way,” which, for better or worse, makes me somewhat more efficient in ZF-based apps, but limits my fun, my programming creativity, and turns me into just another hammer looking for a nail.
To spice things up, I’m going to explore some other solutions. As I’ve seen the name popping up in various locations, I thought I’d start out with the Breeze micro-framework. After a glance over the code on github, it seems that the framework is fairly flexible in terms of organization and implementation, so it should allow me the freedom to create my own solutions to problems that I’ve come to rely on the magic within the Zend Framework to solve.
I challenge you to step outside your normal routine and make your development fun again.
]]>The idea of “personal brand,” is something that I take issue with. In my opinion, saying you have a personal brand is syntactic sugar for saying you have an identity. I made this comment on Twitter:
"I'm not a brand. I'm a person."
(Don’t worry about the hash tag, it’s not important.)
In further discussions we’ve touched on whether one can truly separate his orher personal life from a career. In my opinion, absolutely. My approach to social media separates the various platforms and caters to a specific audience on each. Here’s a couple and how I use them.
Facebook: Personal interaction with family and friends. I don’t post very serious content here, it’s more a playground where my laid-back personality can thrive.
Twitter: I use this mainly for professional contacts with some personal connections and interactions. I must admit I’ve slacked off in the past year or so, and as such, Twitter has lost a significant amount of value to me.
Flickr: This is where I post photos for my photography hobby. I also stay in touch–or sometimes it seems more like stalking–other photographers that interest me.
YouTube: I rarely, if ever, contribute, but I do use this for gear reviews and general knowledge building.
LinkedIn: Purely used a collection of professional contacts for career-oriented networking.
Foursquare: I haven’t really ever gotten into this. While I understand the idea, it seems rather creepy to know where someone is at all times and then to be alerted when your friends/acquaintances are nearby.
As you can see, I keep each medium completely separate. I don’t believe that tying your status message to populate the same message on every social media outlet is a good idea, nor do I feel it provides value to your followers. Again, this is purely my opinion.
What I’m getting at is you are an idividual. Who you work for is only a small component of your identity, and it is completely possible to separate your personal life from your professional life.
One technique I’m going to try out is having a separate account for my work-focused identity. On Twitter, I will have an account@jcarouth for my personal identity and@JeffAtTAMU for my Texas A&M;University-related tweets. I’m going to be tweetingabout what I do at Texas A&M; and hopefully contributing to the Aggie community, even if it’s a small contribution.
]]>When I think about authors that I love and hate, it usually comes down to his or her writing style. For example, I cannot stand essays, books, articles, etc. that are composed of many short, choppy sentences. I always feel like I’m reading a See Spot Run™ story. Because of this, I have adopted a more verbose style.
Being verbose has serious drawbacks. A vast majority of the time I end up having to cut sentences and even paragraphs because I’ve gone off on some tangent and made my simple blog post a 3,000-word essay. That reminds me of a time…just kidding, no tangent to see here; move along.
This impacted my blogging because I ended up deleting a lot of posts I
started that ended up much longer than anyone would be likely to read. I
don’t mean to say that every post must be short. Rather, a post should only
cover enough material to convey the intended message, and it should do so
as concisely as possible. There’s that word again: concise.
The way I plan to get over this real hurdle is to plan my posts better. With pre-writing exercises I can keep myself on topic and avoid adding what ends up being filler content. After all, I want this to be a blog of quality rather than a blog of quantity. Actually I’d like both.
This concludes the Why I failed at blogging series. I hope I helped you get over your hurdles, whether real or imagined. Let me know what hurdles you have to overcome.
]]>