Matthew Lang

... with nothing more than a sheet of paper and the guidance of Steven Pressfield.

Okay it's not a fixie, but I'm really looking forward to heading over to YNOT Cycle HQ to purchase one of the their fine messenger bags in the next few weeks.

via PedalConsumption

Carl Holscher recently wrote about the sharing culture in social media and his preference for remaining private in some of the services he uses.

Yesterday I signed up to the habit tracking service Lift on the recommendation of Curtis McHale. Lift at the moment say they have no settings to keep your profile private, however they do have a setting there to say that you are interested in such a feature.

Habit tracking is definitely something I'm interested in but this is something I would like to remain private in the long term. While I'm only in the initial phase of evaluating this product, I'm prepared to put up with a public profile for the moment. I don't wish to share on Lift mainly due to the reason that I don't know that many people using it and if I wanted to share, it would be with people I know.

And that sums up my rule really for sharing. If I'm a user of a product or service that involves such actions, I'll restrict my account settings so that I remain private or as private as I can be. If there's a number of people I know on that service, then I'll be a bit more public.

I like sharing, but I prefer my daily interactions such as habit tracking to remain private or only to be shared with people I know. So how do you know people without ever actually meeting then? That's another blog post for another day.

Markdown has pretty much been my default markup language for the last few years. All my writing is done using Markdown as well as my journal, notes and other forms of textual data. Although using Markdown for writing is easy now that I know the syntax very well, I still need good tools around me to make the most of Markdown.

I live in my browser on an almost daily basis so I have started accumulating a number of bookmarklets that help me when it comes to using Markdown

Marky the Markdownifier

This is a bookmarklet that converts the current page you're viewing to Markdown. If you're like me and use Markdown for all your documents, then this is really handy. There's also a number of other bookmarklets from Markdownifier that provide different results.

Markdown Link Bookmarklet

Crafting Markdown links from urls is something I do a handful of times everyday. It makes senses then that I automate this little chore.

Jason Seney has a great little bookmarklet that once clicked, converts the current url and title to a Markdown link for you and pops it up in a modal box for you to copy it from.

Kiwi Bookmarklet

Although I use my browser for a lot of day to day work, I use a dedicated client called Kiwi for posting to App.net. The nice thing about Kiwi is that it now supports Markdown style links when you are writing your posts.

Much like the my previous bookmarklet, this one creates a Markdown link for a new App.net post in Kiwi. If you select any text on the page then it will also use that for your link.

This is by no means a finished list. There are probably lots of others addons and extensions and for browsers out there, but I like bookmarklets due to their flexible nature in being able to run on different browsers.

Yesterday I was working on a new feature for a client when I ran into an issue. The ActiveRecord model I was working with had a number of constraints on the table that prevented me from creating a record. I removed the constraints from the table, as I decided that in this case they were unecessary. Unfortunately decisions like this aren't always as straight forward.

I tend to avoid using constraints when possible in my applications, especially when I am using Rails. I can rely on validations and associations to act as 'soft constraints' to my data and ensure that my data is valid. These are also backed up with tests for each model and its validations and associations to other models. This is by no means a perfect solution, but it has sufficed in the past.

Now, a lot of developers might think that constraints are not required as ActiveRecord provides all the necessary plumbing for validating and joining tables together with relationships. That's fair to say if your application is thoroughly tested and doesn't house critical information, but we all want to be good developers so really we should be using constraints where required.

In the past I've worked on a number of healthcare systems that required certain fields to be populated in specific tables. Domains that are directed by rules and regulations on what data you should persist are a great place to use database constraints. Enforcing the data integrity rules on your database reduces the risk for having missing information that could potentially land you in trouble. Domains such as healthcare, law and even education are all examples of domains where by database constraints could be needed.

Applications that also share their data are another good case for database constraints. While you do have validations and associations for your Rails application, can you make the same assumptions about other applications that can access your data? Using database constraints here can ensure that your data remains valid.

In Rails it's all too easy to assume your database is simply a place to hold data, but your database can provide extra validations and checks when needed. I tend to favour not using database constraints until a feature or bug requires that I absolutely need one in place. I find it's much easier to work with code that isn't restricted by countless constraints that have been placed on a table from the start merely because the developer at the time thought that field 'x' was a required field and should have a constraint on it.

It's been six months since I started working as a freelance web developer. In this time I worked harder than I've ever previously worked. And that's a great thing. I'm actually enjoying the work that I do. This wasn't always the case. As a seasoned cubicle worker and a developer in a number of small companies, adjusting to working independently was difficult, but the transition has been worth it. A couple of things have really stood out for me in the last six months.

I'm enjoying coding again

Now that I am using Ruby and Rails on a full-time basis, I've never enjoyed programming so much. Most of my time is spent working on traditional Rails applications. I practice behaviour driven development using Cucumber and RSpec for these applications. In the past I've had limited exposure to Cucumber and RSpec, but the last six months have really seen me gain the experience I needed to cement my knowledge on these tools.

With this new found love for coding, I'm also much more invested in staying as a freelance web developer for as long as possible. To do this, I've been re-reading books like The Passionate Programmer and other books aimed at the Ruby programming language.

I have flexibility

Working from home does require discipline, but there's also the added bonus of being more flexible. I still do a typical day from nine to five, but I've found that without a commute to do I can use that time for other things.

One added bonus is that I can walk my oldest son to school or in the better weather cycle to school with him. It's only a minor thing, but starting the day with a walk (or cycle) to clear your head is better than having to make a daily commute to a remote office.

I'll be making another freelance update in six months (hopefully) with a view to discussing my finances, goals for the next 12 months and looking at side income. Here's to another six months!

Keeping up with posts on a daily basis is becoming a little more work than I anticipated. Previously I would try to write a couple of blogs every couple of days and then maybe a couple at the weekend.

In the last two months though this plan have suffered. Scheduling time in during the day is quite difficult with the the day starting early with a school run and then I need to hit client work as soon as I get back home. At the end of the day it is time to get the kids their dinner, have a play with them and then get them ready for bath and bed. By the time that's done and everything is ready for the next day, it's nearly 9pm and the thought of sitting at the computer is just not that appealing.

I need a plan of sorts. Simply picking off ideas for writing every couple of days is becoming difficult. I have enough ideas, I just need a plan to get them written.

Here's what I'm thinking. I should schedule what I am going to publish in my calendar and then work towards writing the articles that are due to published in the coming week.

One benefit of this is that deciding what to write about is taken out of my hands at an early date. I'm planning on scheduling blog posts at least a month ahead. The second benefit is that I can start writing posts even if they are not due to be published for a week or two.

I'm tired of deciding what to write about not the actual writing itself. So I need to schedule ahead and take that decision out my hands at an early stage. Time will tell if this idea for a publishing calendar pays off or not.

... and Steven Pressfield knows it.

The person who is going to change is going to change anyway. She has no choice. She is impelled by inner necessity. While the person who is not going to change is not going to change no matter how many seminars or retreats she attends or how much money she pays to those who promise to help her make the change.

— How hard is it to turn pro? by Steven Pressfield

via PedalConsumption