Kelli Shaver

We did our first session today. It was review for the adults adjusting to python’s syntax and new stuff for the kid (which is how it will be for quite a while, I think).

We had a lot of fun.

Rich really got into teaching her. He got out the book and the whiteboard and walked her through some basics, then had her run through a few exercises and figure it out. She made errors and then she debugged them.

Today was simple; loops, variables and their basic types, and simple arithmetic. I’d forgotten how much fun just learning those basic things could be when you’re a kid discovering it for the first time. It was really neat to see her make a mistake, pick through the code, figure it out, fix it, anticipate what the output would be, and then get super excited and happy that it all worked.

This should be a lot of fun, assuming we don’t kill each other in the process.

I’ve wanted to get into Python for a while now, but haven’t had the time/a good excuse to do so. Richard is getting back into programming and has decided that Python is where he’s going to start getting re-acquainted. So we thought, “let’s do it together.”

Then we figured, hey, the kid should be old enough to get this stuff now, and it would be good for her to learn some programming fundamentals. It will help her math, science, and critical thinking, and she’ll have another creative outlet.

So we pitched the idea to her and she’s all for it.

Books have been ordered. We’ll be focusing on games with Pygame, to make things fun for all of us. We’ll start from the very beginning, so we can teach her the basics, and then we’ll all get to learn something new together.

I can’t wait to see how this plays out.

I upgraded to Mountain Lion a couple of weeks ago and things have been running slow ever since. My Macbook Air is fine, but my iMac was just dragging. For a while, I thought it was a hard drive problem, because reading files would randomly take forever. However, the hardware kept testing OK. It really felt like a file read problem, though.

I think I’ve found the answer.

Download the new ML compatible version of Onyx, open it up and rebuild the DYLD cache, and then rebuild all font caches. It’s probably a good idea to run the other maintenance scripts while you’re in there, but it was these two things that did it for me.

The difference is night and day. Large files that were taking around 5 minutes to open before this (they’re 750mb files) now open in 3-4 seconds. I also had an issue where the system caret would take 4-5 seconds to switch focus after switching workspaces. That’s now instantaneous again. Overall system-wide performance seems faster, too. Apps open faster and the UI doesn’t lag.

Well, today’s laser capsulotomy went quite well. The procedure itself took about five minutes and my vision returned to normal after only a few hours. My eye felt irritated for a while, but that has gone away now. It does feel tired, though, and after using the computer for a bit this evening, it definitely feels like I need a break.

Laser eye surgery feels really weird. I don’t know how to describe it, exactly. It didn’t hurt at all, but I could definitely feel each laser pulse hitting my eye with a very sharp (as in quick, not painful) force. It would first hit inside my eye, which I would feel, and then the force, I guess, would travel through the soft tissue so that a fraction of a second later, I felt the same pulsing sensation in my top molars.

Anyway, it all went really well and I’m home and will take it easy tonight and tomorrow, and probably get back to work tomorrow evening for a couple of hours.

I maintain (or assist in maintaining) a few open source projects. Over the past few weeks, I’ve noticed some common trends from people submitting code, so I’d like to take a moment to talk about it; what goes on behind the scenes on an open source project, why a project is open to begin with, and how to contribute effectively.

Why is this code open?

The first thing you have to look at when you’re considering using or contributing to any open source project is to ask yourself why that code is open to begin with. Open source code happens for a number reasons, some more altruistic than others, each equally valid. Here are just a few:

1. The developer built something to solve a specific problem and decided to share the end result. Projects like this are essentially developers being nice guys. They’ve had a very specific problem and they’ve solved it and then decided to toss the code onto the internet for others dealing with the same issue. This code is written to do something, and now it does it. Future development by the initial developer may not happen, as they’ve accomplished what they set out to do and have moved on. If this type of project hasn’t been active in six months, don’t bother contributing. Fork it and do your own thing.
2. The developer is solving a generalized problem and wants to share, for the sake of the community. This is the ideal situation to be in. The developer has built something useful that will appeal to a large audience and they have an active interest in making it better and seeing the project grow. These are the best projects to contribute to and are usually quite active and often looking for developers to lend a hand.
3. The open source project is a marketing tool. While it may sound shady, this is a perfectly valid reason for opening up your code. A company that releases open source projects will typically generate a lot of traffic, brand awareness, and community around that project. It’s a means of advertising that says “look what we can do” and may be accompanied by other services such as paid installation and commercial support offerings. While it’s certainly possible to contribute to projects like these, they are usually more tightly controlled, since the company has an image and a reputation to protect.
4. The open source code is a tool for self promotion. This happens when an individual develops something and then puts it out there, to showcase his or her talents and gain exposure as an individual. It’s similar to code open sourced by companies for marketing purposes, but there’s usually a little less red tape to contributing. These projects may not be as actively developed, due to time constraints on the individual, but while they’re still tightly controlled, most indie developers are open-minded about accepting contributions if the code and the functionality is solid.
5. The open source code was meant as a learning project. Here the developer(s) created and subsequently released code for the purposes of learning something new. These projects are often small, and may or may not be of high quality. They can be great seed projects to build ideas and larger projects from, but contributing to them directly can be tricky. A developer learning a new skill will likely be eager to accept feedback and improvements from outside developers, but may potentially lack the experience and discerning eye to filter out the bad commits from the good ones.

What goes on behind the scenes of an active open source project?

This varies a lot depending on the project and the experience level of the developers involved. Some projects fly pretty lose, others are extremely tightly controlled. One thing to keep in mind, though, is that in most cases, no one is directly making money off of their open source code. If the code is maintained by a company, then the needs of the business have to come first. If the project is ran by a team of enthusiasts, no matter how dedicated or skilled the developers are, things like paying for the kid’s braces and fixing that leak in the roof mean that paying work will always come first.

Many times an open source project may have a slow release schedule or a pause in development, or swap out core team members without explanation or obvious reason. The community may not always be privy to the reasons, because they are often personal. It is not ideal, but it is life and it’s often a necessity.

No one likes to see a project they love stagnate, and that is doubly true for the people who are responsible for maintaining it.

The main thing to remember when things like this happen is this: The code is open source. If you do not like the way the current code is being maintained, you can fork it and manage your own offshoot project.

How do you contribute to an open source project?

Let’s say you’ve found a project you love and you want to get involved. You have an idea for a great new feature and you’d like to implement it. So what do you do? Here a few tips.

1. Ask if you can get involved. Managing a team can be stressful. The project maintainers may have all of the help they want. Ask if your contribution is welcome before submitting code.
2. Work on open issues before implementing new features. Most projects have at least one or two open issues. Closing those out before adding new code will help the project remain stable, credible, and useful. It also means a better base upon which to build new features.
3. Don’t submit anything that isn’t accompanied by a working test. This varies from project to project, but for most of the projects I work on, we won’t accept anything unless it is accompanied by a working test case that shows the expected outcome and tests for common issues.
4. Follow the established style. Don’t go changing the code style or formatting conventions used by the project, don’t change the way comments are formatted, and don’t rearrange code unnecessarily. It is disrespectful to the team, highly subjective, and even worse, it can make code tracking and maintenance difficult, since it results in large diffs wherein only the spacing has changed.
5. Follow the branching model that’s already in place. This goes along with code formatting, sort of. If there’s already a method in place for branching, developing, merging, and integrating new features, stick to it. Version control is more than just a big “oh shit” button for when things go bad. Properly maintained code repositories give a thorough history of the lifecyle of the project. Commit history is important.
6. Comment on why you’re doing something, but not what. If you have to comment what you’re doing, then chances are that the code is poorly written. Explaining why you chose to do something, however, is encouraged.
7. Make good commits.This is extremely important, especially any time there is more than one person working on a project. Here are some tips:
   1. Make your commit messages thorough, with a good top line summary and further details in the body of the commit message.
   2. Don’t make unnecessary commits, either. Squash and rebase commits as-needed to make sure that your history is clean before submitting a pull request.
   3. Each commit should only address one issue. Don’t have one commit that adds a field to the user model and fixes a CSS issue in Internet Explorer.

What happens when a pull request is received?

When a pull request is received, it must then be approved before it can be merged into the project. This process can take anywhere from a few minutes to a few weeks, depending on developer availability, complexity of the code, and other work that’s taking place on the project. I do a lot of code reviews, and in general, I’ve seen fairly poor response from the contributing developer with regards to those reviews, so I’d like to take a moment to talk about them.

Code reviews are hard. They are. They’re a little like critiquing artwork, only harder. A lot of a code review is subjective, and a lot of it will relate to the work you’ve done and how it stacks up against and adds to the existing code. In the end, though, a code review is a judge of quality, and no one likes to be judged. Here are a few reasons why your code might not be accepted.

1. It’s bad code. When I do a code review, I don’t sugar-coat. If your code is crap, I will tell you it’s crap. I will do my best to explain why, but I may not always have time. Don’t confuse being honest and blunt with being rude. Don’t get your feelings hurt. Just write better code.— If I tell you that your code needs work, don’t argue. Fix the code.
2. It’s not a good fit or is too specific to your individual needs. If your code simply isn’t a good fit, you’re welcome to explain your reasoning, and I’m open to re-thinking how something should be implemented, but ultimately, just because you want to implement feature X, it doesn’t mean it belongs in the project as a whole, or that the way you implement it is a good fit.
3. The timing is wrong. Projects in active development have a lot of things going on and may be managing contributions from many outside sources. To top it off, there are a number of valid reasons in which the developers may not make the project road map public (the expectation of deadlines vs. personal obligations, to maintain a competitive edge when the code is used for marketing purposes or for securing new leads, etc.). Sometimes your code will be rejected because all of the pieces just don’t line up. When this happens, be patient. Give the developers time to reach a point where the code is stable and mature enough to accept your request. Wait until the next round of planned layout revisions is done before adding your own custom CSS, etc. Step back, wait, submit again when it’s appropriate.
4. The maintainer hates you and wants to make you suffer. This only happens after about 8 of your previous pull requests have been rejected. Seriously, though, sometimes personalities just don’t mesh. If you’re consistently getting shot down on a project, don’t continue making everyone, including yourself, miserable. Move on to something else, or fork the code.

Other thoughts

Here are a couple of random observations to finish things out. Maybe they’re not pretty, but they’re accurate and worth mentioning.

1. Open source does not always mean open development. Open source code means you’re free to download, use, modify, and often times re-distribute the code as you see fit. It does not, however, automatically mean that a project is even open to outside development or that it has to accept contributions evenly from all developers.
2. Open source code doesn’t entitle you to anything. Just because the code is released to the public, even if it becomes popular, it doesn’t mean that the original developer is under any obligation to continue development, release updates, fix bugs, or even relinquish control of the project to another person. It is essentially free software that’s being given away. Take it for what it is. Expect nothing more from it, and be appreciative of the projects where you do get more.

So there you go, some quick thoughts on open source code, what goes into it, why, and how to contribute. Maybe this will be helpful to someone. Maybe it was a cathartic rant. Either way, the main take-away should be this:

Open source projects are not maintained and managed like commercial software is developed (in most cases). FOSS is motivated by different reasons and developed under a different paradigm. Other things like bills and family take priority, and developer choice is a fact of life, whether you agree with it or not. Be respectful, ask where you can help before diving in head-first, and don’t take it personally if your code isn’t accepted into the project.

Oh, and one last thing…. just about every open source project out there needs someone who’s willing to come along and help out in the form of writing and translating documentation.

Tonight I came across this great list of thoughts on being a programmer. I thought I’d add a few of my own.

• Respect the fact that most code has a life cycle that will extend beyond your personal involvement in the project.
• Always leave the code cleaner than you found it.
• The occasional all-nighter is good for the soul
• Too many all-nighters is bad for your health.
• This ratio changes when you hit 30.
• Comment the whys not the whats.
• Commit. Commit. Commit.
• Don’t pirate tools that help you earn a paycheck.
• Work on things that interest you.
• Learn something new as often as possible.
• Step wildly out of your comfort zone from time to time.
• The occasional impossible deadlines are opportunities to feel like Batman.
• Respect yourself.
• Stand up for yourself.
• Don’t reinvent the wheel unless you can make a better wheel.

I thought I’d take a moment and write about my Sublime Text 2 setup. I’ve customized it a bit to make it easier to see, so I just want to quickly run through the (no doubt highly subjective) steps below. Most of my changes involve improving contrast and readability.

Install the Soda theme and use Soda Dark - Sublime’s default look is great, but personally, I prefer Soda Dark. I find that light text on a dark background causes me less eye strain. Having the sidebar (which I always leave visible) match the editor’s main window eliminates the glaring contrast between the two, which can be quite distracting and uncomfortable to look at, especially in full-screen mode.

Install the Railscast color scheme - Like most developers, I can be pretty picky and stubborn about what theme I use for syntax highlighting. I’ve found that the Railscast color scheme is great. It offers a good mix of highly visible colors that contrast nicely with one another, and the background, without being too bright to cause glare. The one slight modification I have made is to eliminate pure white, opting instead for a very, very light grey.

Set your font to Iconsolota - This is a super clean font that looks just as good at larger pixel sizes as it does small ones, which isn’t something that can be said about a lot of programming fonts.

Enlarge the font to a comfortable size - Being able to see a decent chunk of a line of code is important and really short lines are annoying, but it’s possible to find a balance. I bumped the font size up to 16pt (you can either set this in your user preferences or just tap cmd + a few times, just like you’d zoom in your browser) and then run the app full-screen so I can still see longer lines of code. Even in split view (my default), line length is pretty good.

Modify the dirty file indicator graphic - You can find it in Packages/Theme Soda/Soda Dark. The file you’re looking for is “tab-dirty.png.” There are other dirty file indicator graphics, but I find that this is the big one. I’ve modified mine like so:

No more squinting at the tab to see if it’s unsaved. :) You can use mine if you like.

Install a block cursor plug-in - Unfortunately, Sublime doesn’t come with an option to use a block cursor. This can make finding the rather thin caret somewhat difficult. There are a few block cursor plug-ins floating around the internet. Here’s one that I’ve modified to work outside of Vintage mode.

Learn your keyboard shortcuts - Every programmer should learn as many keyboard shortcuts as possible to save tiem and energy, but it becomes especially important when you have difficulty seeing. Keyboard shortcuts mean you don’t have to spend any time or energy finding and keeping up with a mouse cursor.

There you go. I hope this will be of help to someone out there. :)

For all of those times when I’ve thought to myself, “you know, six eye surgeries just isn’t really enough.”

I feel a little remiss for not mentioning Icenium before. I’ve meant to blog about them on several occasions.

Icenium is a cloud-based development environment for building cross-platform mobile applications. They’re still in beta and, admittedly, I haven’t had as much time to experiment with their service as I would like to, but what I have seen so far, I have been impressed with.

They have a downloadable Windows IDE and a browser-based editor. There are plans for a Mac version of the desktop software, but honestly, I have to say that the browser-based solution is extremely polished and definitely quite usable. It’s impressive - one of the best online editors I have seen. They also offer in-browser device simulation for Android and iOS.

I would love to see them incorporate some sharing and collaboration features, but I’m sure that will come once the application moves out of beta.

These guys are definitely worth looking into and definitely a service I would pay for.

This morning I got an email from their brand manager, Anthony. He and I have emailed back and forth a couple of times, and he’s a super-nice, very approachable guy. He was writing to let me know that I’d won this.

Holy crap… thank you so much, guys! This is absolutely amazing. As I delve deeper into the world of mobile development, I find that I have ended up purchasing several mobile devices for testing purposes. Simulators are great, but they just can’t express the full experience of using an application on the device. This adds up to a big expense pretty quickly. Getting these four awesome mobile devices is going to be a huge help to me in the months ahead. I currently own exactly none of them.

The real kicker? I didn’t even realize I was entered into a drawing. I had signed up for a beta account because the app looked awesome.

1. I had to get an RMA and do an exchange with Google. My device is plagued with what seems to be a common defect wherein the left side of the screen does not sit properly within the bezel. It was minor at first, barely noticeable, but now, after two weeks, it’s starting to get worse, so back to Google it goes. My replacement tablet will be here tomorrow. Hopefully it won’t have the screen lift issue, or any of the other problems that seem to be present in the first run of devices.
2. Despite this fact, I love this little tablet.

What do I love about it?

The 7in form-factor - I wasn’t sure if I was going to like this at first, given my problems with my eyesight and the fact that I’m so used to the 10.1in display of the iPad, but 7 inches feels much more comfortable. It’s more like holding a paperback novel. It makes for much more comfortable reading. It also lends itself very well to typing. The on-screen keyboard in portrait orientation is the perfect size for thumb-typing. I can type pretty quickly and accurately with it. That’s nice.

The amount of customization - There’s no doubt Android gives you much more flexibility and freedom to customize than iOS does. Being a perpetual tinkerer with a bit of OCD about things like, oh, what icons are on my home screen, this is a huge bonus. I love the fact that I can tweak so much of the user experience. Even just being able to add a couple of widgets to the home screen (local weather and a music player) are a big improvement. My Nexus 7 feels very personalized. It feels like my tablet, whereas the iPad just feels like a nicely polished device that I happen to use.

Light weight - As you would expect with the smaller form factor, the Nexus 7 weighs in at about half the weight of an iPad. This is really noticeable when reading for long periods of time.

Are there things about it that I don’t like? Yeah, a couple…

Not as many apps - The Android marketplace is smaller than the Apple app store. There isn’t as much software available and there’s a lot of software that’s of lower quality than would typically be accepted into Apple’s walled garden. That said, I was able to find the software to do everything I wanted, but the difference in availability an quality is noticeable.

The internal speaker kind of sucks - It’s not bad given the size of the device and you can’t expect internal speakers this small to be very high in quality to begin with, but compared to the iPad speaker, the Nexus 7’s offering is pretty weak. It’s rare that I use the external speaker, though.

This first run of tablets seems to be plagued with some hardware issues. That’s not uncommon in any first-gen device (yellow iPad screens, anyone?), but the Nexus 7 seems to have quite a few issues, the screen lift that I’m experiencing being the most common. It feels like Asus’ quality control slipped a bit in the name of fulfilling all of those pre-orders on schedule.

Other thoughts:

Being able to pop the back of the Nexus 7 and (presumably) replace the battery is nice, though given the lifespan of batteries these days, and how quickly the market is advancing, I’d say I’ll end up replacing the Nexus 7 with some newer model long before the battery gives out. In general, though, the Nexus 7 feels like something I could fix if a single component failed, and that’s a something I can really.

By comparison, it makes the iPad feel a bit heavy and awkward, bu, there are still several things for which I do feel the iPad is better and most of those revolve around media. All of the music in the house is shared via iTunes and that sort of seamless integration between devices feels really nice. The larger display also makes things like gaming or watching videos more enjoyable. The 7in size of the Nexus 7 may feel more comfortable for reading and typing, but when it comes to looking at photos or watching movies, a slightly larger screen is always nice.