I’ve been putting it off for a long while but my recent PC upgrade finally pushed me over the edge so yes, I finally have a dedicated NAS in my network.
Author: sylv3rblade
Add Gitlab CI to your Hanami project
I host my personal projects in gitlab because it’s free and it gives you free runners for your ci. I recently started studying the Hanami framework in ruby and when it was time to build the test suite, I initially couldn’t properly get it to work because of a strange error.
My initial gitlab-ci.yml was as follows
image: ruby:2.5
services:
- postgres:latest
variables:
DATABASE_URL: 'postgresql://postgres/budget_tracker_test'
POSTGRES_DB: budget_tracker_test
HANAMI_ENV: test
cache:
paths:
- vendor/ruby
rspec:
before_script:
- gem install bundler --no-ri --no-rdoc
- bundle install -j $(nproc) --path vendor --quiet
script:
- echo 'Trying to create db for develop'
- bundle exec hanami db prepare
- echo 'Trying to create db for test'
- HANAMI_ENV=test bundle exec hanami db prepare
- rspec spec
Pretty straightforward right? But for some reason I was encountering this error:
Could not find executable in your PATH: `createdb` /builds/sylv3rblade/budget_tracker/vendor/ruby/2.5.0/gems/hanami-model-1.2.0/lib/hanami/model/migrator/postgres_adapter.rb:104:in `rescue in call_db_command' /builds/sylv3rblade/budget_tracker/vendor/ruby/2.5.0/gems/hanami-model-1.2.0/lib/hanami/model/migrator/postgres_adapter.rb:97:in `call_db_command' /builds/sylv3rblade/budget_tracker/vendor/ruby/2.5.0/gems/hanami-model-1.2.0/lib/hanami/model/migrator/postgres_adapter.rb:36:in `create' /builds/sylv3rblade/budget_tracker/vendor/ruby/2.5.0/gems/hanami-model-1.2.0/lib/hanami/model/migrator.rb:287:in `create' /builds/sylv3rblade/budget_tracker/vendor/ruby/2.5.0/gems/hanami-model-1.2.0/lib/hanami/model/migrator.rb:332:in `prepare' /builds/sylv3rblade/budget_tracker/vendor/ruby/2.5.0/gems/hanami-model-1.2.0/lib/hanami/model/migrator.rb:247:in `prepare' /builds/sylv3rblade/budget_tracker/vendor/ruby/2.5.0/gems/hanami-1.2.0/lib/hanami/cli/commands/db/prepare.rb:26:in `prepare_database' /builds/sylv3rblade/budget_tracker/vendor/ruby/2.5.0/gems/hanami-1.2.0/lib/hanami/cli/commands/db/prepare.rb:17:in `call' /builds/sylv3rblade/budget_tracker/vendor/ruby/2.5.0/gems/hanami-1.2.0/lib/hanami/cli/commands/command.rb:85:in `call' /builds/sylv3rblade/budget_tracker/vendor/ruby/2.5.0/gems/hanami-cli-0.2.0/lib/hanami/cli.rb:57:in `call' /builds/sylv3rblade/budget_tracker/vendor/ruby/2.5.0/gems/hanami-1.2.0/bin/hanami:6:in `<top (required)>' /builds/sylv3rblade/budget_tracker/vendor/ruby/2.5.0/bin/hanami:23:in `load' /builds/sylv3rblade/budget_tracker/vendor/ruby/2.5.0/bin/hanami:23:in `<top (required)>' /usr/local/lib/ruby/site_ruby/2.5.0/bundler/cli/exec.rb:74:in `load' /usr/local/lib/ruby/site_ruby/2.5.0/bundler/cli/exec.rb:74:in `kernel_load' /usr/local/lib/ruby/site_ruby/2.5.0/bundler/cli/exec.rb:28:in `run' /usr/local/lib/ruby/site_ruby/2.5.0/bundler/cli.rb:424:in `exec' /usr/local/lib/ruby/site_ruby/2.5.0/bundler/vendor/thor/lib/thor/command.rb:27:in `run' /usr/local/lib/ruby/site_ruby/2.5.0/bundler/vendor/thor/lib/thor/invocation.rb:126:in `invoke_command' /usr/local/lib/ruby/site_ruby/2.5.0/bundler/vendor/thor/lib/thor.rb:387:in `dispatch' /usr/local/lib/ruby/site_ruby/2.5.0/bundler/cli.rb:27:in `dispatch' /usr/local/lib/ruby/site_ruby/2.5.0/bundler/vendor/thor/lib/thor/base.rb:466:in `start' /usr/local/lib/ruby/site_ruby/2.5.0/bundler/cli.rb:18:in `start' /usr/local/lib/ruby/gems/2.5.0/gems/bundler-1.16.2/exe/bundle:30:in `block in <top (required)>' /usr/local/lib/ruby/site_ruby/2.5.0/bundler/friendly_errors.rb:124:in `with_friendly_errors' /usr/local/lib/ruby/gems/2.5.0/gems/bundler-1.16.2/exe/bundle:22:in `<top (required)>' /usr/local/bundle/bin/bundle:23:in `load' /usr/local/bundle/bin/bundle:23:in `<main>' ERROR: Job failed: exit code 1
So I looked up some of the discussions on the issue tracker on Hanami’s github and I found this still open issue with Hanami still requiring a local postgres instance :|. Anyway, cart before the horse, I ended up using the postgres service while manually installing postgres in the ruby image just so I could run my specs proper.y
Here is my `gitlab-ci.yml` now
image: ruby:2.5 services: - postgres:latest variables: DATABASE_URL: 'postgresql://postgres:[email protected]/budget_tracker_test' HANAMI_ENV: test cache: paths: - vendor/ruby before_script: - apt-get update -qq && apt-get install -y -qq postgresql postgresql-contrib libpq-dev cmake - gem install bundler --no-ri --no-rdoc - bundle install -j $(nproc) --path vendor --quiet rspec: script: - bundle exec hanami db prepare - bundle exec rspec spec
After pushing this to gitlab, viola!
Starting fresh and with a new goal
I started thinking about it early last year and I guess it’s nigh time I took my current hobbies seriously (I mean, hey I’ve given myself loads of time to prepare already).
It’s a work in progress but I’m hoping to get things set up quick so I can move forward with other, more important things (like actual shoots) :D.
Use PRY with rails console
I love pry.
Aside from prettifying the output of your terminal when debugging, it is a bit more handy thanks to it’s extra features. Here’s a railscast to see what you can do with pry.
If you want to use pry as the default shell for rails console you can simple open up your config/development.rb file and add:
MyApp::Application.configure do
# start copying here
silence_warnings do
begin
require 'pry'
IRB = Pry
rescue LoadError
end
end
# end copying here
end
and ensure that pry has been added to the Gemfile.
or if you want a one liner approach (one line of config and a bundle install to be clear), just add the pry-rails gem to your Gemfile
gem 'pry-rails', :group => :development
Back to my roots
After a looong blogging hiatus, I’m finally posting an update.
A lot has happened (some good, some bad) but for what it’s worth, I’ve learned LOTS of things. Now that I have some time on my hands and have found the need to reorganize, I thought I’d handle a bit more of my postings online.
Some currently in progress:
- Simplicity for Project Alter (and Project Alter itself)
- Crown Carnival
- Reviving some of my default blogs including this one
- A few photography stints ( still looking for an account to handle this. maybe a DA account)
DRYing HTML using content_for and helpers
I recently encountered a scenario where I needed to dry up some HTML code for a navigation snippet that needed to appear on both the top and bottom of my main content. Here’s a snipped version of the code
<div class="tablenav top row">
<div class="somenavigationfunction"></div>
<div class="anotherfunction"></div>
<!--
Some code for the navigation here
-->
</div>
<div class="display row">
<!--
Main display page here
-->
</div>
<div class="tablenav bottom row">
<div class="somenavigationfunction"></div>
<div class="anotherfunction"></div>
<!--
Some code for the navigation here
-->
</div>
The code that I need repeated divs with tablenav classes. The usual way to go about this is using content_for and yield:
<% content_for :tablenav do %>
<div class="tablenav top row">
<div class="somenavigationfunction"></div>
<div class="anotherfunction"></div>
<!--
Some code for the navigation here
-->
</div>
<% yield :tablenav %>
<div class="display row">
<!--
Main display page here
-->
</div>
<% yield :tablenav %>
A bit DRY-er now right? The problem with this approach is that both instances of the yielded output sports the same set of classes. This is good most of the time but in my current usage, I need the top instance to use a “top” class while the bottom one needed a “bottom” class for proper padding. I could simply add another div to wrap each of the yield lines but that’s requires me to edit the css file to reflect the change. Here’s the solution I came up with using content_for and helpers:
<% content_for :tablenav do %>
<div class="tablenav top row">
<div class="somenavigationfunction"></div>
<div class="anotherfunction"></div>
<!--
Some code for the navigation here
-->
</div>
<%= nav_block("top") %>
<div class="display row">
<!--
Main display page here
-->
</div>
<%= nav_block("bottom") %>
And the code for the helper
def nav_block(location = nil, &block)
content_tag("div", content_for(:tablenav), :class => "tablenav #{location} row").html_safe
end
Just fire up the page in your browse and watch it work :). Now how exactly did this works? Turns out that content_for can also be used to output it’s contents. If you’re wondering why yield wasn’t used is because it simply doesn’t work with helpers. If you tried to use yield, you’ll end up with the following LocalJumpError: no block given (yield).
Important Note: I’ve only tested this on Rails 3.x, Rails 3.2 to be exact.
Hope that helps.
[Linux] changing file or folder permission recursively
I recently encountered a permissions problem when installing a new application on my Wiredtree VPS. The crux of the problem was some of the necessary files have the wrong access permission thereby rendering the application almost inoperable. To fix that, I needed to change permissions of a whole lot of files and folders. And while I could’ve changed the permissions individually, it would’ve taken quite a long time so here’s what I found to work
To set all the folders to 755:
find . -type d -exec chmod 755 {} \;
To set all files to 644:
find . -type f -exec chmod 644 {} \;
Let’s say you want to change the permissions of files that end only in .rb and set it to 755 (pattern escaped with slashes)
find . -name \*\.rb -exec chmod 644 {} \;
Simple right?
Leaving the current nest
So yes. I finally made the decision to write THE letter.
I’ll be forwarding it to my superiors on the 15th and I’ll be signing my contract with the new company on Monday. More monies plox.
ArgumentError: invalid byte sequence in US-ASCII
If you’re on Ruby 1.9.2 and have started getting this error when trying to install gems (either by gem install or bundle install), your environment is simply missing the LANG variable and is loading up US-ASCII by default.
To fix this, simply run the command below before installing anything
export LANG=en_US.UTF-8
or to make it more streamlined, add it to your .bashrc or zshrc (if you’re using the zsh shell).
Built a new PC over the holidays
I was planning on saving things up for Ivy Bridge but seeing that it’s release date is around 6 months (or more) away, I decided to bite the bullet and splurge a bit to build a new gaming PC.
Here’s what I’ve bought to build my rig:
- Intel i5-2500K
- Asus P8P67-M B3
- G.Skill RipJaws 8gb (2x 4GB 1600Mhz) DDR3
- Seagate 500GB 7200 Sata 3
- Cooler Master V8 CPU Cooler
- Cooler Master Storm Enforcer
- AeroCool Strike-X 80PLUS 600W PSU
Total cost, around 30K Php
Why the i5-2500k? It’s the most popular CPU in Intel’s current Sandy Bridge line and with good reason. First off, it’s the cheapest unlocked processor, the next item on the list is the i7-2600K and while offers a bit of improvement over the 2500K, the added cost for me is simply not worth it.
My initial build had me going with the Asus P8P67-M B3–take note that I say initial because I’m going to replace it soon with a Z68 board (either an Intel one or another Asus board). Mind you if you’re looking for a cheap way to mount your Sandy Bridge processor, the P8P67-M is a good board, It’s got the basics laid down like support for 1600 Mhz DDR3 DIMMs, support for fairly large CPU cooler (in my case the Cooler Master V8), SATA 3 6Gb/s ports, USB3, etc. For my use case however, I’ll be better off going with a Z68 board due to Virtu, Intel’s multi-GPU solution implemented at board-level. Basically the gist of Virtu is that you’ll be using Sandy Bridge’s on-chip GPU until your applications demand something beefier. I’m still looking at reviews but I think my gist is spot on so correct me if I’m wrong as I’m basing this on a several weeks old review from Anandtech. Apparently I read things wrong, Virtu appears to be implemented on application level indicating that there will be a performance hit when you opt to use the IGP and discrete GPU at the same time :/ Darn.
I stuck with a Seagate 500GB 7200 because I still have my 1TB Seagate 10K Raptor which I’m currently using as my primary drive. I wanted to get an SSD for this but that’ll have to wait for my Ivy Bridge (??? hopefully haha) build.
Looking at the list, there’s no GPU from the things I’ve bought. I still have two DX10 GPUs which have served me well, the GeForce 460 GTX and the Radeon 4850 1GB SE. The current build uses the Nvidia card because I had stability issues with the 4850 :/ I’m still going to use for my HTPC once I have purchased the new Z68 board.
Now for the case, I opted for the Storm Enforcer because my first choice, the 690 II Advanced was sadly out of stock :(. Compared to my older case, the Thermaltake V3, the Storm Enforcer was a hell of a lot easier to work with due to it’s massive size and features. The price is well worth the looks too 🙂
I got the v8 and Strike-X PSU for kicks (admittedly it was an expensive choice >_> but it looks quite well with the case doesn’t it?).
Is it worth it?
In a word, yes.
My computer is now leagues faster than my older rig which was based on a Core 2 Duo processor and it feels a lot snappier than my 2011 Macbook Pro who’s performance is quite bottlenecked by the 5400 RPM drive (something I plan to remedy in the near future). In terms of games, I can play Metro 2033 on High (with a few tweaks) and Skyrim on Ultra at 1920 x 1080 resolution considerably well (with a quite a few dropped frames on areas with high particle count thanks to my video card and it’s limited bus :/). One of the best perks I’ve had is mirroring games on my 32 LCD TV so my “audience” can enjoy watching me play :)).
My new build will be an i3-2100 HTPC/Fileserver which I plan to get this January to replace my Buffalo NAS.
