I’ve been using Vim for several years now and I’ve found a few features that I use everyday. I like to keep things very simple and I don’t use many plugins, but I do use a few that I find very useful.

Here are the most useful ones:

Normal mode

:ls

This command lists all the buffers that are currently open in Vim. It’s useful when you have multiple files open and you want to switch between them quickly. After you list the buffers, you can switch to a buffer by typing :b <buffer number> or :<buffernumber>b. I use it a lot.

:ju

This command lists all the jumps that you’ve made in the current session. It’s useful when you want to go back to a previous location in a file.

ctrl+o

This command jumps to the previous cursor position. It’s useful when you’re editing a file and you want to go back to where you were before.

ctrl+i

This command jumps to the next cursor position. It’s useful when you’re editing a file and you want to go back to where you were before.

* (star)

This command searches for the word under the cursor. It’s useful when you want to find all occurrences of a word in a file.

# (hash)

This command searches for the word under the cursor backwards. It’s useful when you want to find all occurrences of a word in a file backwards.

:Explore

This command opens the file explorer in Vim. It’s useful when you want to navigate through your files and directories.

:vs

This command splits the window vertically. It’s useful when you want to view two files side by side.

Visual mode

V

This command enters visual mode. It’s useful when you want to select text in a file.

v

This command enters visual character mode. It’s useful when you want to select a character in a file.

ctrl+v

This command enters visual block mode. It’s useful when you want to select a block of text in a file.

ctrl+V

This command enters visual line mode. It’s useful when you want to select a line of text in a file.

Registers

It’s very useful to understand how registers works and what types of registers are available.

Very simple example: register “% is the name of the register that contains the current file name. You can just “%p to paste the current file name to the current line.

Marcos

I don’t make heavy use of macros, but when changing large blocks of text, they can be very useful. You record a macro with q and then you can play it back with @.

Plugins

I use a few plugins that I find very useful:

• vim-lsp: Language Server Protocol support for Vim: most useful recently in combination with ctrl+o and ctrl+i to navigate through the code exectution paths
• copilot.vim
• Fugitive: A Git wrapper for Vim
• ctrlp.vim: Full path fuzzy file, buffer, mru, tag, … finder for Vim

l o l

Obviously a meme has been improved:

And then finally, while I’m writing this article, Rick Rubin himself shares this:

Before that though, the reddit post has gone viral where someone built a whole python codebase without knowing python and now AI is having a hard time comprehending the codebase and suggesting solutions and bug fixes.

Reception

Obviously, there’s a significant pushback from this. Seems like programmers are terrified, but not necessarily because of AI potentially taking our jobs. Mostly due to code quality and comprehension concerns and extrapolating that into the future and where does this lead us.

On the other hand, various types of builders, indie hackers, solopreneurs, products managers, marketers, people who I’d call accelerationists (mostly on X platform) are hyper excited about the possibilities and they are fully onboard. There’s no shortage of opinions that senior devs are soon to be visiting the unemployment office en masse. Well, we shall see.

However, I will risk saying that an immediate reaction from someone who works with large scale software for a living is that the future is bright for software engineers either way.

Vibe coding in different contexts

So is Vibe Coding good or bad? Of course - it depends on the context, the purpose and the outcome.

First of all - I don’t think that companies and their engineering departments are willing to just start experimenting with blindly vibe coding and deploying the results to production all of the sudden. This is just not going to happen in mature organisations. TDD, code reviews, continuous integration are all there for a reason and they are not going anywhere. From my experience, no sane organisation is really deploying incomprehensible code to production and I don’t see this changing with AI. On the contrary, I’d expect engineers these days to be extra vigilant and careful during reviews knowing copilot et al. can be used to generate code. It’s really on you, as an engineer, to understand your change, regardless how the code was produced. The industry is definitely experimenting with harnessing AI to deliver code, but in the end, for now at least, the code is overwhelmingly still written by humans and it’s still reviewed by humans as well.

On the other hand, indie hackers, lone programmers, solopreneurs - sure, vibe code all the way to production - who cares? As long as it works I guess. If you’re a solo founder, the risks of doing this are very low. Even if the codebase will escape your comprehension, you can always start from scratch and learn from past mistakes. Next time maybe you’ll take smaller steps, refine the process (although iterative development is an insight that software engineers might have, but it’s probably not something people think about when starting vibe coding as non-programmers - interesting food for thought here as well for further exploration).

Vibe coding by non coders

The problem the aforementioned redditor created is not new either.

I will risk stating that humans have created spaghetti code since the beginning of computing. Not only by amateurs. Actually, probably mostly by professionals.

The result of a failed vibe coded project really isn’t much different than, for example, barely hacking things together with a wordpress installation. Installing shit load of different plugins just to arrive at the conclusion 2 years later that nothing works anymore. Versions get out of date, plugins get abandoned, you can’t upgrade anything any more, etc. Of course Wordpress installation is just an example here, but we’ve seen it in various codebases at some point in our careers as web developers or programmers.

"Junior devs can't code any more"

One more interesting case emerging with vibe coding is junior devs. I don’t have a lot of information here as I rarely interact with people new to the industry these days.

Initial insight emerges though and it’s mostly what you’d expect: New Junior Developers Can’t Actually Code.

That said, I think I need to agree with Gergely Orosz that “new devs can’t code” is a story as old as time. It is not new and most likely every single generation of programmers has been saying this about the upcoming generation of new programmers.

More interesting question is - how will new devs grow and evolve with all the modern tooling in place? Extrapolating this into the future I believe can give us valuable insight into the future of software engineering discipline itself.

Robots are updating our codebase as we speak

Let’s also not forget that we do have a lot of semi-smart automation already predating AI code generation. Dependabot for example updates your dependencies on a daily basis almost with no human intervention. It’s a standard practice these days to have it running on your repos. We are literally letting a robot update our dependencies, merge and deploy the code to production without any human supervision TODAY. This is enabled by having a test suite you’re fairly confident in, a continuous integration pipeline to run said test suite against each change and a continuous deployment pipeline to get it out into the world automatically. Tomorrow’s autonomous code generation capabilities are a step further from this.

Applying Vibe Coding

First of all, let me state that I find it truly amazing that vibe coding can actually work. The fact that you can literally talk to a model, give it an idea you’d like see built and it will give you the code, deployment instructions, explanations of various steps, having a coherent, long lasting conversation about the whole project, decisions, ideas, solutions, further improvements, etc is remarkable. I do feel the AGI.

At the same time it’s easy to dismiss this whole premise as something that will never work in a serious software engineering environment due to already mentioned problems. But we have to agree that AI and AI-driven-software-development are here to stay. That tooling will continue to improve and that it will change the landscape of software production forever in the near future.

It’s already changing all aspects of building software products from marketing, product engineering, operations, delivery and maintenance so it begs a question about what it all means for the future of software engineering as a discipline as it’s practiced in larger and more “mature” organisations?

Products with AI dna

Let’s speculate a bit about some near future product capabilities that might then drive software engineering changes and practices:

Self healing software - similarly to dependabot upgrading dependencies, we might see self adjusting and self healing systems where bugs are automatically detected and triaged. Fixes would be automatically implemented and deployed to production. This would require integration between several systems - error reporting software, observability systems, version control, possibly ticketing systems and company chat systems for notifications and orchestration. Software engineers would be responsible for architecting and maintaining these integrations as well as monitoring the AI agents that would be doing the work.

Prompt Management Systems - with more systems being integrated with LLMs and AI agents, versioning working prompts could become a thing. Tracking changes to prompts, understanding the impact of changes on the codebase, marking sections of the code that were AI generated and tracking their corresponding prompts would be a new spin on the traditional version control systems.

Auto Generated features - imagine an end user requesting a feature via a form or a chatbot and the feature being automatically verified for safety, implemented and deployed to production without or with minimal human intervention. On top of standard tests, security checks, there likely will be specialized AIs for reviewing the suggested changes, security audits, etc. Finally, humans might be signing off on the change before it goes live. Again, software engineers will be needed to drive, implement and maintain these processes.

Conversation Driven Development (aka Vibe Coding Enterprise Edition) - software development might be shifting more into the conversational space about “what” more instead of “how” (think Cucumber and BDD but driven mostly by AI. Specialized software might be needed to bridge the gap between nondeterministic AI output and deterministic code driven by detailed tests and/or formal verification before actual implementation is done by the AI. We’ll need skilled software engineers to conduct the test driven process and create tooling to verify that AI is generating correct code.

Productionizing vibe coded prototypes - surely there will be a period where programmers will be tasked with making vibe coded prototypes production ready. These can be done by non-programmers as part of A/B tests or experiments, validated on some small group and handed over to make it production ready.

More interactive documentation - automatically generating and maintaining documentation that you can talk to and ask questions about. With code and observability in context so that the experience is fully integrated and you can jump around between documentation, code and observability tooling seamlessly to gain insight and understanding about the system you’re analyzing.

Others - likely other “copilot” type of collaboration tools will emerge. AI agents that monitor systems performance and automatically suggest improvements on an ongoing basis. AI agents tracking conversations and technical discussions and suggest opportunities to eliminate waste, gaps or improvements to various processes. AI driven system observability: new tooling will emerge that will improve reaction time and time to recovery in cases of production incidents.

Summary

Currently vibe coding, depending on who you ask, is either an abomination, source of future problems and demise of our own making or a magical, egalitarian, equalizing, democratizing tool that allows people to bring their ideas to life without having to learn to code. As software engineers, whether we like it or not, we will be working with AIs throughout the whole software development lifecycle fairly soon if not already. The vibe coding meme is a hint on where things are headed. It’s a glimpse of the future of software development. It’s our job to imagine and make tools, build solutions, practices and design processes that will allow us to harness the power of AI to build better software products safely and efficiently.

In 2013, I nonchalantly wrote a blog post titled “How I thought I wanted to become a digital nomad”. It’s been almost 10 years now since that post and I must say that for me, it aged quite well actually.

Summary:

In 2013 I experimented with digital nomadism by being almost constantly on the go, which was quite unsustainable. I got back with lessons learned and worked towards finding a stable remote position that would allow for location independence and sustainable remote lifestyle. I’ve been fully remote for almost 6 years now with additional challenges of having two young kids (5yo & 2yo atm). These are my mostly unstructured thoughts regarding my journey, challenges and takeaways.

~~

My main point in the article was that the experiment with travelling while working was proving to be unsustainable the way I was doing it. Being on the move all the time was not the smartest way of digital nomading and I learned that first hand I guess, but hey, that was the plan and I mostly made it work.

The takeaways sticked with me though. I published that article when I was already back home where I got myself employed again, yet I vowed to make the location independence idea work long term in a sustainable fashion.

It took me 5 years since that initial nomading experience to get to the place where I wanted to be really. I focused on finding a stable, engaging business to work for that had an established remote work culture or was at least open to the idea. The fact that I found one PLUS I got to write Ruby there was just a perfect coincidence.

And then covid happened and everyone suddenly had to go remote!

However, circa 2015, it wasn’t yet obvious that remote work would be the norm and the majority of the roles were still permanent, office based. I lived in London at that time and got a job that allowed working remotely but with certain limitations. I stuck around for over two years effectively in a hybrid mode where I worked mainly on premise, with a remote getaway once in a while (amazingly including Australia). After that it was time to go fully remote - I came back to Poland, became a contractor for the same company, completing the journey to become fully location independent (within some sane boundries ofc, like tax residency, timezone that made sense, company policy etc).

Which leads me to the key take aways of a wannabe nomad from reflections of this past decade, half of which I spent working 100% remotely, predating covid.

Reflecting back to original goals from 2013, what I was really after was increased freedom that comes from location independence without sacrificing my growth as an engineer. I’m now convinced that a permanent base combined with a conscious utilization of possibilities given by remote work is where the sweet spot is for me.

Also, do keep in mind, that I’m not retired, I’m not an entrepreneur and I don’t have a money making product that allows for a ‘4hr workweek’, yet! lol. What I do is ordinary, full time, software engineering for an insurance company with meetings, standups, coding, writing documentation, etc.

Some of the challenges:

• pre covid, when I was often the only team member that worked remotely, meetings really sucked for me. Even with decent conferencing tech, the echoes in the rooms, missed comments between the members because the mic hadn’t quite caught what had been said, being self concious because I’d be the only person remote with my face being streamed into the room and cast on a huge screen didnt really help. So when remote was imposed on everyone due to covid, the playing field suddenly evened out for me, the tech got better almost immediately and the quality of the meetings went significantly up for me, fast. Part of the quick transition was likely due to the fact that the company was half way there anyway, so we were quick to evolve and adapt, but the improvement and better use of available technology surely played a major role as well.

• finding time and motivation to take care of myself was a challange, especially during covid. I have two young kids, so when I worked from home as soon as I was out of office I was mostly occupied by family stuff - semi solutions included lunchbreak runs, going out to work in public, preferably cycle there, take shifts with wife to go do sth every odd day.

• less peer contact, so less ad hoc discussions, possible learnings, inspiration even - I don’t have a good solution to this. Online communities and meet-ups in the real world partly work, but it won’t fill in the gap of informally interacting with the people you work with. Company off sites do help.

• commuting on a daily basis is quite a bodge, but working from home day by day without a break in the routine is as well. There’s a certain buzz and agency that going out, commuting and interacting with the environment gives you. It’s missing when WFH and longterm it can lead to apathy and other things you don’t want imho. Not sure who needs to hear this, but you need to go and do stuff in the real world. At least I do. And I don’t think I’m very unique. If anything, I can probably bear with a bit more isolation than a statistical person can.

These generally worked for me (unordered):

• finding a nanny for the kids when they’re not in nursery/kindergarden (duh!) - next level is travel with nanny - haven’t tried it, have friends who have who were happy with it. Quite a costly option though, ofc.

• having a permanent base - as long as you settle on a city/place you actually enjoy, having a permanent address, tax residency, etc helps a lot and takes away quite a bit out of the hussle. For me it’s Warsaw and I don’t want to live anywhere else If I can help it. I can travel extensively, but this is home and it turns out, I really enjoy having a home!

• working from home is not exactly synonymous with working remotely. To make it truly work for your benefit, you need a lifestyle around it - it’s easy to get sucked into staying home for extended periods of time if you don’t have other stuff going on

• not relying on a sophisticated workspace setup - the simpler the better, as this contributes to the freedom of movement (I do have a large screen that I often use at home, but I dont depend on it for productivity etc)

• getting used to focusing in different scenarios, being flexible regarding working environment like working in public

• when working in public, remember about secops / privacy considerations. Know what you are discussing and who can hear it - mostly it’s not a problem for me, but one needs to be aware of the surroundings and topics discussed. If it’s sensitive, make sure you’re at home / private office, etc

• making actual use of the increased location independence - it’s an oportunity to change the environment every now and then, take a working retreat abroad or in other city in your country, rent a cabin in the woods with good internet connection, etc

• pairing / mobbing when coding

• still taking holiday / sabbaticals to do proper travelling

• doing a “micro due diligence” of a place you plan to work from before actually depending on it for work - going there on a weekend or on a day without any meetings and checking out the vibe, noise, internet quality, etc. Limit surprises that can negatively affect your work later. (workfrom.co or others could work depending on your location)

Epilogue

Value proposition of remote work has not changed for me one bit since the original post. The perspective did change because we’re a family with two kids now. We’re not really nomads, but we definitely benefit from a permanent remote work setup. IMHO the core reason of being location independent and more in control of your time is still as valid as it used to be in 2013. Remote is to be embraced, although we need to acknowledge it’s coming with a set of challanges and is definitely not for everyone. You can make it work though and I wouldn’t trade it for anything.

Who's this post for?

In general, I wrote it for people who are seriously considering getting into programming either as a hobby or to get an entry level job or an internship at some point. Now, you won’t become a coder overnight but investing your time and effort is worthwhile, I can promise you that.

TL;DR

Some of the many options to start out is starting with a tutorial on programming like the briliant Learn Ruby The Hard Way or Learn Python The Hard Way. After that, building a simple webapp with the help of an application framework like Ruby On Rails, Django or Meteor by following one of the abundant tutorials on one of these technologies listed here. It’s perfectly fine if you’re confused about what choices to make. If so, go here and start learning Ruby. Then start building a simple app following The Rails Tutorial. You really can’t go wrong here. Numerous people have proven that Ruby and Rails are viable choices and both are a lot of fun to learn. Read more arguments on why rails at the bottom of this page.

Am I too dumb to program a computer?

In short, NO, you’re not. But before we go any further though, we must establish a rough baseline.

While I belive that you can learn to program without prior knowledge, if you’re serious about learning to code, it’s still important to know the basics of computing and hardware architecture. You don’t have to know the internals and mechanics of how computers work from top to bottom, but general working knowledge of using and interacting with a computer is kind of obligatory.

In this article, I am assuming that you have good working knowledge of using computers and generally understand the technology stack. If you can barely tell apart the browser, internet, operating system, hard drive memory, ram memory and the difference between the two, windows, linux, macs, etc, you might want to check out those basics first.

Some very good books have been written on the subject and these include:

• HOW COMPUTERS WORK by Roger Young
• Code: The Hidden Language of Computer Hardware and Software
• .. and a whole bunch available for free at freecomputerbooks.com

There are also some very good video resources out there, like the very popular CS50 from Harvard University.

So, having that long intro behind us, let’s start with the actual things you should consider when planning your learning strategy.

Have fun

While it might be quite intimidating at first, you’ll soon realize that it can actually be a lot of fun. The fact that pretty quickly, you could be building something useful or entertaining is really compelling. The sheer idea, that you could just build something, out of absolutely nothing, show it to others and recieve feedback is a very empowering thing to think about in the context of programming.

Work hard

First of all, prepare to work hard. Be ready to put in the hours of work, study, sometimes periods of frustration and many times awe and fullfillment. Programming a computer is just not the easiest things you can learn. It’s very rewarding, but it’s a nontrivial task. I can’t stress enough how self motivation is important here. I’ve seen many people quit after being stuck on some problem for a while or who were just not prepared to work that hard. It’s not that obvious. You really have to find the motivation to keep going, and not many people stress that enough. You need to hussle and push through it. Having said that, it’s not as difficult as it seems at first and now is truly the best time to start. It really has never been easier to learn how to code. The amount of tools, resources, knowledge, examples, open data and so on are so abundant that it makes my brain hurt. Use that. Capitalize on virtually all the human knowledge that just sits on you laptop. We live in truly empowering times when it comes to knowledge and technical skills and it’s almost your duty to humanity to use that opportunity well!

Make it relevant & think big

Make the programming experience relevant and fun to you. Definitely start small, but also start with a bigger picture idea about what you could possibly be able to bring to life if only you could know how to code it. Relevance and well defined goals are key to success. Make your goals achievable, but be bold on your vision to retain motivation.

Be proactive

This is a huge one and really touches the subject of mentors as well. Being proactive is reaching out to find the knowledge and foundation out there. Also it means coming up with your own little projects and problems to work on. Seeking your areas of interest basically. Use Wikipedia intensly, stackoverflow.com, plain old google, social media, newsgroups and irc channels. Ask questions but be prepared to put the work into research by yourself instead of recieving ready solutions.

Seek out mentors

This one is actually most beneficial if you have a little knowledge already, but I’ll still mention it because I think that this is not emphasized enough in most of the resources out there.

If you’re just starting out, just get on it and do your research as you go along. You can find my starting point recommendations at the bottom of this post.

Having mentors is one of the crutial steps on the path to mastery. Most successful people of this world claim they had a mentor and as an aspiring programer you should consider finding your mentors as well. After you dive in and start to get the main ideas and more importantly - start to realize what you don’t know yet (which is almost everything), start reading famous programmers’ books and code and seek out more experienced people in your area. Real world interaction with smarter and more senior hackers will be very influential and will make you progress faster.

There are many resources out there, that will be far more comprehensive that I wish this post would be. For starters, check out Jeff Atwoods’ Recommended Reading for Developers.

Stay hungry

The process of learning never really ends. It sounds trivial, but it’s true. Stay hungry for knowledge and keep improving. Take on harder and harder tasks. Once you learn something new, you start to see how it unfolds a new rabbithole of further questions and ideas. Keep going deeper and remember that mastery is a constant progress. Like with most hard things, it’s a marathon, not a sprint.

So How do I start already?

Ok, preaching aside, how do you actually start?

First of all, although many people would probabily disagree, you don’t have to become a computer scientist in order to create software. I wouldn’t go down the road of reading tons of theory books before trying to write simple programs first. Many successfull coders have proven that you can just dive in by following tutorials and start filling the knowledge gaps as you go along and discover more about the craft.

There are really many paths to getting started and honestly I don’t think that it really matters what kind of language or framework you choose. You start with C, C++, Java, PHP, Python, Ruby or Javascript and all those paths will be fine, although C,C++ and Java tend to have maybe a slightly steeper learning curve than so-called dynamic languages.

It really does not matter if you first go to codeadcademy, edX or Become a Programmer, Motherfucker. These are all viable options and you can choose what suits you best.

Having said that, one of the strategies that has always worked for me is immersing yourself in as many tutorials, articles and videos on the subject as you can possibly can. No matter what language and/or framework you’ll choose. The main point being here is to just start and do your best to stick with it making adjustments as you go along.

I am attaching a list of noteable resources at the bottom of this post, that you can go through.

Now, how about the famous Ruby On Rails?

Among the vast amount of choices presented above, one definitely stands out in my opinion. It is Ruby On Rails framework.

Here’s why:

(relative) Simplicity

Ruby On Rails uses the Ruby programming language, which is modern, easy to use and expressive. It does a good job of abstracting away the complexities of building a web application, so at the beginning of you journey you can focus on messing around and building simple things without going deep into techincalities. Of course, later on you’ll want to dig deeper and actually get to know the theory and engineering under the hood. But for now, you just don’t need that, as your goal is to create something and make it publicly available.

Huge, active community

Rails has one of the most active communities of hackers and builders out there. Most of the beginner questions can be easily found online on forums, Q&A sites like stackoverflow.com blogs and mooc courses.

Useful skill

Rails is quite popular among new and existing startups, because it significantly cuts down the time of shipping a Minimum Viable Product. It lets you quickly build a prototype of something real and go from there.

List of technologies and tutorials
.. by no means comprehensive

General Computing

• How Computers Work?
• Harvard CS50 Class - HIGHLY RECOMMENDED
• CS101 Class
• edX - Introduction to Linux
• Survival guide for Unix newbies
• Senior Guide To Computers

Ruby & Ruby On Rails

• Learn Ruby The Hard Way
• ruby-lang.org
• Rails For Zombies
• Programming Ruby
• _why's (poignant) guide to Ruby
• The Rails Tutorial
• The Rails Guides
• Practicing Ruby

Python & Django

• Learn Python The Hard Way
• The Python Tutorial
• Obey The Testing Goat
• Tango With Django
• Dive Into Python
• Google's Python Class
• Writing your first Django app

Javascript

• Mozillas' Learning The Web
• Learn Meteor.js
• Discover Meteor
• Felix's Node.js Guide
• How do I get started with Node.js @ stackoverflow.com

Others

• C Programming and C++ Programming
• C Programming For Beginners @ Udemy
• Harvard CS50 again
• The Java™ Tutorials

Reverting the aws-sdk gem to version < 2.0 fixed it for me:

In Gemfile:

gem 'aws-sdk', '< 2.0'

As Trevor Rore from Amazon writes:

NameError: uninitialized constant AWS
If you receive this error, you likely have a dependency on aws-sdk and have updated so that you now have version 2 installed. Version 2 uses a different module name, so it does not define AWS.

Read more here.

ERROR:  Error installing nokogiri:
     ERROR: Failed to build gem native extension.

    /Users/aps/.rvm/rubies/ruby-2.1.5/bin/ruby -r ./siteconf20141218-1242-b4o2ja.rb extconf.rb
checking if the C compiler accepts ... yes
checking if the C compiler accepts -Wno-error=unused-command-line-argument-hard-error-in-future... no
Building nokogiri using packaged libraries.
checking for iconv... no
-----
libiconv is missing.  Please locate mkmf.log to investigate how it is failing.
-----
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers.  Check the mkmf.log file for more details.  You may
need configuration options.

Provided configuration options:
     --with-opt-dir
     --without-opt-dir
     --with-opt-include
     --without-opt-include=${opt-dir}/include
     --with-opt-lib
     --without-opt-lib=${opt-dir}/lib
     --with-make-prog
     --without-make-prog
     --srcdir=.
     --curdir
     --ruby=/Users/aps/.rvm/rubies/ruby-2.1.5/bin/ruby
     --help
     --clean
     --use-system-libraries
     --enable-static
     --disable-static
     --with-zlib-dir
     --without-zlib-dir
     --with-zlib-include
     --without-zlib-include=${zlib-dir}/include
     --with-zlib-lib
     --without-zlib-lib=${zlib-dir}/lib
     --enable-cross-build
     --disable-cross-build

extconf failed, exit code 1
Gem files will remain installed in /Users/aps/.rvm/gems/ruby-2.1.5/gems/nokogiri-1.6.5 for inspection.
Results logged to /Users/aps/.rvm/gems/ruby-2.1.5/extensions/x86_64-darwin-14/2.1.0-static/nokogiri-1.6.5/gem_make.out

I headed back to official Nokogiri website and reviewed their installation guidelines, which basically say that on OS X it should work out of the box, unless you encounter the libiconv issues ;).

But still, they claim that the following should do the trick:

% brew unlink gcc-4.2 # you might not need this step
% gem uninstall nokogiri
% xcode-select --install
% gem install nokogiri

Unfortunately that did not work for me, so I started investigating further.

I tried the solution from my previous blog post, which fixed the problem before by passing the additional parameter for non-standard iconv installations:

gem install nokogiri --with-iconv-include=/usr/local/Cellar/libiconv/1.14/include \ 
  --with-iconv-lib=/usr/local/Cellar/libiconv/1.14/lib

with no success, but really I wanted to get it working cleanly this time, without the custom steps and/or hacks involved.

Unlink the libiconv at brew!

So what's the deal here? With up-to-date Xcode developer tools installed, iconv actually installed at /usr/bin/iconv and still failing to install by pointing to the brew version of libiconv, I tried to unlink the libiconv at brew and finally got it working as expected!

So please find the actual steps I took, below:

# install the latest ruby 2.1.5
% rvm install ruby-2.1.5
% brew unlink libiconv
Unlinking /usr/local/Cellar/libiconv/1.14... 125 symlinks removed

% gem install nokogiri # you can skip it and and go directly to installing rails of course
% gem install rails —version 4.2.0.rc3
% rails -v
Rails 4.2.0.rc3

Nice and clean now, rockin' on a bleeding edge of Rails again :)

In this short post I’ll describe the steps needed to start baking your new apps in the newest edge rails version.

And since I’ve been quite negligent in keeping my own system up-to-date, I’ll also take this opportunity and describe the process of upgrading to match the current versions of ruby, ruby gems and rails.

Please note that I am using OSX 10.9.2 Mavericks so your setup might be slightly different.

First of all, there is a bug in rubygems >2.2.2 that prevents you from installing rails 4.2, so make sure, you have ruby gems v. 2.2.2 on our dev machine.

The error I was getting was:

  ERROR:  While executing gem ... (Gem::DependencyError)    Unresolved dependency found during sorting - activesupport (>= 4.0) (requested by sprockets-rails-3.0.0.beta1)
  This bug was reported here:  https://github.com/rails/rails/issues/16609 - keep watching for a fix and update your ruby gems after the fix will have been issued.

So this does the job:

  gem update --system 2.2.2

When developing in Rails, a good strategy to keep your setup in order is to use RVM to manage different versions of Ruby. You can learn more about RVM here. Keep in mind though, that there are alternatives

Anyway, to install current stable Ruby version:

Ugrade to the most stable RVM version:

  % rvm get stable

Then run:

  % rvm install 2.1.2

After successful ruby installation you can check out your ruby versions by running:

  % rvm list

  rvm rubies

  ruby-1.9.3-p125 [ x86_64 ]
  * ruby-2.0.0-p247 [ x86_64 ]
  => ruby-2.1.2 [ x86_64 ]

  # => - current
  # =* - current && default
  #  * - default

Finally, to create a new gemset dedicated for your edge rails versions, run:

  % rvm use ruby-2.1.2@rails4.2 —create

To install Rails prerelease:

  % gem install rails —pre

Confirm your new rails version:

  % rails -v
  Rails 4.2.0.beta1

During Rails install, I had to tell nokogiri where to find the libiconv dependency.

  gem install nokogiri -- --with-iconv-include=/usr/local/Cellar/libiconv/1.14/include --with-iconv-lib=/usr/local/Cellar/libiconv/1.14/lib

After rerunning

  % gem install rails —pre

.. Rails 4.2.0-beta1 installed correctly.

Verify your gem list:

  % gem list

  *** LOCAL GEMS ***

  actionmailer (4.2.0.beta1)
  actionpack (4.2.0.beta1)
  actionview (4.2.0.beta1)
  activejob (4.2.0.beta1)
  activemodel (4.2.0.beta1)
  activerecord (4.2.0.beta1)
  activesupport (4.2.0.beta1)
  arel (6.0.0.beta1)
  bigdecimal (1.2.4)
  builder (3.2.2)
  bundler (1.6.2)
  bundler-unload (1.0.2)
  erubis (2.7.0)
  executable-hooks (1.3.2)
  gem-wrappers (1.2.4)
  globalid (0.2.3)
  hike (1.2.3)
  i18n (0.7.0.beta1)
  io-console (0.4.2)
  json (1.8.1)
  mail (2.6.1)
  mime-types (2.3)
  mini_portile (0.6.0)
  minitest (5.4.1, 4.7.5)
  multi_json (1.10.1)
  nokogiri (1.6.3.1)
  psych (2.0.5)
  rack (1.6.0.beta)
  rack-test (0.6.2)
  rails (4.2.0.beta1)
  rails-deprecated_sanitizer (1.0.2)
  rails-dom-testing (1.0.2)
  railties (4.2.0.beta1)
  rake (10.1.0)
  rdoc (4.1.0)
  rubygems-bundler (1.4.4)
  rvm (1.11.3.9)
  sprockets (2.12.1)
  sprockets-rails (3.0.0.beta1)
  test-unit (2.1.2.0)
  thor (0.19.1)
  thread_safe (0.3.4)
  tilt (1.4.1)
  tzinfo (1.2.2)

To fix this now, you need to change your Gemfile to fetch branch lm-rails-4-2 of Devise directly from github, like so:

gem 'devise', :git => 'https://github.com/plataformatec/devise.git', :branch => 'lm-rails-4-2'

Please note, that for production use, you should probabily wait for new Devise release, where this bug will be merged.

More info at: https://github.com/plataformatec/devise/pull/3153

Around three months ago, the company I worked for got suddenly closed.

The reasons for this, are quite irrelevant to this article, but in short, the investor backed out and the ongoing development of a product I was mainly involved in, had been suspended.

I didn’t plan for this scenario. The timing was off, I just came back from vacation and had had a semi long-term plans based on a stable situation with my current day job.

But it had happened and, practically, overnight I had to figure out my next moves for the next couple of weeks.

The idea of working remotely has always been compelling for me. Somehow I always knew that at some point in time, I’d like to “escape the nine to five”, travel the world with my laptop, make money doing freelancing gigs, experience life to the fullest, and yet maintain the technical skills without becoming rusty.

And suddenly - here I was, without a lot of attachments, no mortgage, kids, with some savings on my account and no immediate plans for the nearest future.

Having said that, the decision was pretty simple - this was a great opportunity to do some traveling, that I’ve always wanted to do.

Choosing the location was also quite obvious and for a number of reasons I finally bought a ticket to Bangkok.

Southeast Asia FTW!

I’ve already done some traveling in Europe and wanted to see some other parts of the world.

I’ve spent a year in States and would love to come back, but I wanted to depart as soon as possible and American visa policy is both expensive and still quite hard to get for Polish citizens.

Australia is just too damn expensive for longterm travel on budget, especially when, like me, you’re into scuba diving, kite surfing and numerous other outdoor activities that are generally quite pricey, even in “cheap” countries.

So, Southeast Asia was an obvious choice. It’s the mecca of budget travelers. There are countless blogs owned by people who work online and travel this region and, I guess, that it’s just a thing that one has to experience at least once in his or hers lifetime.

Fortunately, I had some minor clients that I worked for after hours when I still had a job, so while much, much smaller, some income while on the road was pretty much secured.

After around one month of preparations (vaccines, gear, minor planning), me and my girlfriend packed our bags (42 liter Northface Duffels - highly recommended, although not the best choice if walking long distances) and was off to Bangkok with a general idea to travel around Thailand, Vietnam, Laos and Cambodia (which, by the way, we later corrected to Thailand, Vietnam, Cambodia and Indonesia, but this is different story).

I’ve been on the road for two months now, working online for the clients back in Poland. The gigs mostly include maintaining and modifying existing websites, but I’ve lately managed to secure one larger Rails project that needs to be done from scratch.

So far, this has been a very rewarding, educating (although not really in the technical sense) experience, but there are some major drawbacks to this kind of lifestyle, that I’d like to share.

They mainly involve two recurring, significant problems that I found I was facing:

1) Limited types of projects, you are able to tackle while on the road;

2) Illusion of freedom of choice concerning your location;

Only small, simple projects

This is a huge disadvantage for me. Initially I was OK with doing some minor gigs that would just keep me afloat, but the reality of this is that now, I have a constant feeling of underachievement and wasting time.

Yes, it’s fun to open your laptop in your bungalow on Koh Phangan, right next to a beautiful beach, chat with your client or hack around on the project, knowing that after the work is done, you’ll jump in a 30 degree (Celsius) warm waters of the Gulf of Thailand, or better yet, go free diving on numerous reefs around, but this comes with a price.

Also, I don’t believe that long-term travel is actually waste of time. There are numerous advantages and opportunities to grow while traveling, but you can’t have the best of both worlds all at once unfortunately.

If you like challenges and have the need of constant self development in your area of expertise, it’s just very hard to find the necessary balance here.

Of course it all depends on the kinds of projects you manage to get, and technical problems you face during implementation, but let’s be honest here - knowing that you’re on a constant move, quite often facing unpredictable internet access quality and desire to make the most out of your traveling experience you just can’t be doing some substantial, challenging work, that involves hours of analysis, discussions and complicated programming.

There are just too many distractors around and too much stuff to see after (and sometimes during) work.

I can already tell, that some people are now thinking that it’s just a matter of self-control, planning and proper preparation, but for me it never was the case.

I think of myself as a very self-motivated guy. My clients are happy with the work that I’m doing and I always manage to meet the agreed deadlines, while maintaining high quality standards I set for myself.

This is not the point. The point is, that having some significant experience on mid-sized projects, involving some non-trivial programming, I observe, that most of the kind of work I’ve been doing at my day job, would be either impossible or extremely challenging to get done while on the road.

This limits my options to taking only the kinds of projects that I know I’ll be able to easily handle by myself, within very predictable timelines and involving limited amount of research.

And to be completely honest, it’s just not enough. I believe that working with a team of people that are more experienced and smarter than yourself is crucial for your development, and as a freelancer, doing minor gigs involving some MVC/CRUD application programming, you just miss out on a world of possibilities to grow and learn.

Don’t get me wrong though - I keep busy, try to learn something new everyday and strive to continue to develop my skills as a programmer. For the past two months, however, I just felt I lack the exposure to real-world problems that you get to face, when on the job in an organization that everyday tackles problems way more sophisticated than you’d be able to tackle on your own. Whether it’s a small startup or a large corporation is irrelevant here.

The location independence illusion

Now, I absolutely think that working remotely is possible and it’s a great way for (a) developers to stay “location independent” and (b) companies to cut costs a bit, making use of available technologies.

The problem here is quite different though. Working on the road gives you a kind of illusion of location independence. While it’s true you can work for one company being physically “anywhere” in the world, in order to get some substantial amount of work done, you actually need a comfortable spot, good internet connection, peaceful environment and ideally some facilities around like a gym/yoga school park or a bar - whatever you’re into.

Even though it might be obvious, during my travels I found out the hard way that creative, meaningful work, requires some routine. Changing your location once a week, working from benches, hammocks, cafes, bars and hostel floors is a cool way to fund your vacation, but it certainly doesn’t help you when tackling hard programming problems.

Thinking about different possibilities and layers of these problems, currently I have a couple of solution ideas listed below:

1) get a remote-friendly job that fits your skill set and ambitions. Move every quarter or so. Stay in one place for a while. Immerse yourself in the culture and rhythm of the chosen destination, rent a nice room or apartment with a legit desk and a chair you can actually sit in for longer than 3hrs (unless you’re one of the standup-work-environments kind of guy, than forget it), get the routine going. Live somewhere you like, and when you feel like change, do some research and go for it.

2) get a real job, in real office, do stuff you love and challenge yourself (actually, always do that, ofc), negotiate long-term vacations and go traveling for instance, for two months every year or so (details irrelevant).

3) keep working on that “passive income” wordpress site and/or travel blog that makes you tons of cash and travel till you puke ;)

SIDENOTES:

• I personally dislike the ‘digital nomad’ term. There is something inherently ‘douchy’ about this title.
• If interested, please follow my travel adventures at airseasummit.com
  
  
  
  
  

This is the first post in this blog. It runs on Jekyll and GitHub Pages.

I will be posting something soon.