• Cryptocurrency — Everyone talks about it and I kind of get how it works. But I have no idea how it’s built or how to mine it.
• Machine Learning/AI — I know some basic theory but I’ve never successfully built a program that has *learnt* anything. This area seems to be an ongoing trend so it’s probably worthwhile for me to build a project that uses Machine Learning.
• Website design — I still have no idea how to do this. I don’t know how to use the tools and I don’t know how to make something look good. I can tell a good website when I see one. But how do I translate into my own site?
• Functional Programming language — Does Javascript count as one? I have no idea. What is a functional programming language? Why does everyone tell me I should learn one? I want to get better at learning languages so why not start with a functional one.
• Containers — Kubernetes, Docker, are they even related? I have no idea how any of these work. Why are containers good? What can they contain?
• Native App development — There’s only so much I can learn in a year. But I do want to learn about app development at some point.
• GraphQL — I’ve seen this used by Github and other companies. But I have no idea how this works. I think it’s a replacement for a REST API. But how do I implement it? And why is it good?
• Javascript front end framework — There are so many frameworks out there. And I know nothing about any of them. I’ve heard good things about Vue, but honestly, I don’t know what problem they’re trying to solve.
• Fancy AWS stuff — I’ve heard people talk about Athena and Glue. But I have no idea what they are or what they achieve. The AWS ecosystem is huge, I’d want to learn more about it.

This is scratching the surface of the things I don’t know about. There’s probably plenty more. But as I continue on in 2019 I want to spend time researching some of these topics. And hopefully by the end of the year I’ll know a little bit more.

—

I’d love to hear what’s on your list of things to learn about in 2019. Let me know in the comments below!

When I first made the choice to become a freelancer and I had no idea where to begin. I reached out to my old manager who was the sales lead/product manager at my old company. We covered a range of topics starting with how to get leads. To copyrighting a business logo. To dealing with taxes. After the conversation, I had a grasp on what I needed to do. I’ve been a freelancer for 7 months now and I’ve realized that there were some topics he didn’t cover. Here’s the advice I would give past me.

Setup a standardised project pipeline.

Standardise the way you start every client project. This starts with documentation. Use Trello or a free CRM and keep it up to date. Use these tools to keep track of quotes, requests, and questions. Also spend some money on software, like Xero, that can send and track invoices. At some point, you’ll start approaching every client project the same way. You might have a standardised set of questions. Or a standard timeline for getting a project started.

Spend time researching — Longer than you think.

Time estimation is one of the hardest parts about freelancing. I‘ve always struggle with estimating the length of a project. By spending time researching you can make a much better estimate. I recently realized the value of research when working with another freelancer.

He would break down a project into smaller features. For each feature, he would add a checklist of tasks to complete. He also added any information about potential database models. This included any proposed columns and also any relationships with other models. Finally, he estimated the time per feature and any potential time sinks. This became his roadmap for the project. It also uncovered any potential questions that he could bring up with the client.

Value pricing.

I’ve never implemented value pricing. I would feel like a fraud if I spouted advice about how to do this. From what I’ve read, value pricing seems to be the path that every freelancer should take. You can earn more than hourly pricing. And you can do this without working yourself to the ground.

I won’t go too in-depth with this concept. Instead I suggest you subscribe to Jonathan Stark’s free email list about value pricing. It’s a six part email newsletter explaining the what and how of value pricing.

Get better at client communication.

I find communication hard to master. Should you answer an email immediately with the client? Are they going to care about small, incremental updates? Should you wait until you have a large update which could take weeks or months?

In my experience, over communicating is better than not communicating enough. Most of the time this comes in the form of emails. Sometimes through calls or video chats. Use technology to make communication easier. Start a slack channel and invite them to use it. Let them know what hours you’re available for questions. Set boundaries so they don’t interrupt you during deep work. It’s hard to build trust with a client when you’re working remotely. Constant and meaningful communication helps alleviates this.

David Copeland recently gave a talk at Rails Conf 2017. He tackles the idea of being an effective remote developer. If you’re looking to improve in this area, I recommend watching the video below.

What advice would you give to a budding freelancer? Let me know in the comments!

If you enjoyed this post hit that ❤ button!

First of all we need to add rspec-rails and factory_girl_rails to the Gemfile.

group :development, :test do
  gem 'rspec-rails', '~> 3.5'
  gem 'factory_girl_rails'
end

Next run:

$ bundle install
$ rails generate rspec:install

This will generate a spec/ folder inside your application. You can remove the test/ folder if it exists.

Next create the file spec/support/factory_girl.rb and paste in:

# spec/support/factory_girl.rb
RSpec.configure do |config|
  config.include FactoryGirl::Syntax::Methods
end

This makes method calls less verbose. For example instead ofFactoryGirl.build you can now use build.

Next, uncomment the following line in spec/rails_helper.rb to autoload files in the support/ directory.

Dir[Rails.root.join('spec/support/**/*.rb')].each { |f| require f }

Everything is now setup. The next step is to generate a test and create a factory. Then we need to make sure everything passes.

Generating a test and running it

An RSpec test will be generated whenever you generate a model or controller. RSpec also offers generators to generate a test only. For example here’s how to generate a test for the model, Widget.

rails generate rspec:model widget

Check the RSpec documentation on generators to learn more.

Fun fact: with Factory Girl installed, a factory will also be generated when you generate a test.

Here are the files created when running the above RSpec generator. This should also generate a Factory Girl file spec/factories/widgets.rb.

# spec/models/widget_spec.rb

require 'rails_helper'

RSpec.describe Widget, type: :model do
  pending "add some examples to (or delete) #{__FILE__}"
end

# spec/factories/widgets.rb

FactoryGirl.define do
  factory :widget do
    
  end
end

To run the test:

bundle exec rspec spec

✅ RSpec + Factory Girl installation

I would love to hear your thoughts on how you set up your testing environment. Is this how you would setup RSpec and Factory Girl? Also, I’m trying to get better at technical tutorials so if you have any thoughts let me know!

This year I’ve found one thing that I (really, really) want to achieve:

I want to move to Chicago, IL.

I want to do this for love, to have new experiences, and to become a better developer. This post holds me accountable for my future actions. I want to share my failures and triumphs with you.

Of course, I’m a bit hesitant (scared) to change. It’s much easier living in your comfort zone than challenging yourself. But 2017, a year of challenges, feels like the right year to start afresh.

What’s the one thing you want to achieve this year?

P.S HAPPY NEW YEAR! 🎉🎉🎉

I used these links specifically to help setup my Ghost theme.

• Getting Started — basic introduction into setting up your theme.
• Structure — tells you the files you need and a suggestion on how you structure your theme.
• index.hbs file example code — Code to get a list of posts to show on your home page.
• post.hbs file example code — Code to display a single post.

What do I put in the package.json?

Package.json is a file that just contains some information about your theme. I wasn’t really sure what needed to be in the package.json file. It wasn’t specified anywhere in the docs. In the end I just copied the code from the default Casper ghost theme:

{
   "name": "Casper",
   "version": "1.2.7"
}

Footnote:

After reading through the npm documentation for package.json, I’m starting to realise that every package.json file will probably have the same format.

I knew I needed to write better commit messages so I read probably the ultimate article by Tim Pope which is age old and has probably been read/referenced by a lot of people. So begun my journey to writing better commit messages.

I’m now about day ten into this habit forming exercise and I’ve learnt a couple of things:

- More detailed commit messages make you think about the code you write. It makes you think about the files you are changing and the effects that your change will make to the program.

- I’m terrible at working out whether I should write detailed messages or short succinct ones. Should I list all the changes when you can see the files that I changed with the commit? I just don’t know. I guess that skill might come in the future (hopefully).

- Writing a good commit message is hard. But writing one helps me see the overall goal of the project and how my commit is working towards that goal.

If you’re still writing one line commit messages for major commits. Stop it. Seriously.