Trying out chruby and ruby-install and installing Ruby 2.2.2 with ruby-install was giving be the error:
|
1 2 3 |
directory not found for option '-L/usr/local/Cellar/openssl/1.0.2k/lib' |
Setting the LDFLAGS env var solved this for me:
|
1 2 3 |
export LDFLAGS=-L/usr/local/opt/openssl/lib |
To run Alacritty without spawning a new terminal window you can use Automator to create a new application wrapper.
Create a new application document and choose Run Shell Script as the action. Then simply add the path to your built Alacritty and save the document to your Applications folder.
Trying out Alacritty and can’t live without the Dracula theme. So here it is. Just added it to your alacritty.yml
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
# Colors (Dracula) colors: # Default colors primary: background: '0x282a36' foreground: '0xf8f8f2' # Normal colors normal: black: '0x000000' red: '0xff5555' green: '0x50fa7b' yellow: '0xf1fa8c' blue: '0xbd93f9' magenta: '0xff79c6' cyan: '0x8be9fd' white: '0xbbbbbb' # Bright colors bright: black: '0x555555' red: '0xff5555' green: '0x50fa7b' yellow: '0xf1fa8c' blue: '0xcaa9fa' magenta: '0xff79c6' cyan: '0x8be9fd' white: '0xffffff' |
Made a really annoying mistake today while writing some code to delete data out of Redis.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
def delete_keys cursor = "0" loop do cursor, keys = redis.scan(cursor, count: SCAN_COUNT) keys.reject! { |key| keep_key?(key) } redis.del(keys) unless keys.empty? break if cursor == "0" end end def keep_key?(key) keep_keys.any? { |keep_key| key.include?(keep_key) } end def keep_keys flattened_keys << transaction_id end |
The mistake was in the final method keep_keys. Every check to see if a key should be rejected I was adding an element to the flattened_keys array over and over again, causing my deletion to slow down over time. A simple change to memoize the keep keys made the process go from never finishing to, completing in a few seconds.
|
1 2 3 4 5 |
def keep_keys @keep_keys ||= (flattened_keys << transaction_id) end |
A great library for adding typeahead support to your site is Twitter’s Typeahead.js. Even better is the excellent Bloodhound suggestion engine which comes with it. Sometimes though if you’re dealing with a remote suggestion engine like Elasticsearch’s completion suggester you don’t need to run remote results once again through another suggestion engine. Bypassing Bloodhound is as simple as hooking your own source function into your Typeahead definition.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
$('input#keywords').typeahead({ highlight: true, }, { name: 'brands', display: 'value', source: function(query, syncResults, asyncResults) { $.get('/search?q=' + query, function(data) { asyncResults(data); }); } }) |
One of the core ideas of Rails is convention over configurations. Models go in app/models, controllers go in app/controllers and views go in app/views. The danger is that we stick to those conventions no matter what and we end up either with fat controllers, fat models or even worse a mixture of both.
Many times we don’t take enough advantage of Ruby’s object oriented nature and the ability to extract functionality out into separate classes. Doing so can make an entire application easier to extend, understand and test. I have tried approaching this from different angles in different projects and I’ve found that the two main hurdles to getting this right are naming classes and putting them in the right place.
I have experimented with naming such as UserAuthenticator and UserAuthenticationService, and always end up feeling uncomfortable I constantly wonder if the other name is better or if there is a better way entirely. Using agent nouns in class names is considered a code smell, but the more that I think about it the important part is picking a choice and sticking to it. I was looking at the GitLab repository and noticed that they’ve done exactly that, everything is named in a consistent manner. I think many may dislike that but it makes things extremely clear and easier for anyone contributing as to what they should name their classes and where they should put them.
All too often I find that CSS quickly becomes a real tangle of clashing styles and names. No matter how hard I try something always ends up breaking the styles of something else. Moving to SASS helped a lot but I find on the flip side I end up with styling that’s overly nested.
I’ve recently come across BEM which is CSS methodology for naming classes. BEM stands for Blocks, Elements, Modifiers. I’ve previously looked into SMACSS but still found things fell apart (probably because I’m doing it wrong). BEM looks a lot simpler and easier to maintain. A simple example would be the following styling for an article.
|
1 2 3 4 5 |
.article // Block .article__body // Element .article--featured // Modifier |
I’m not going to go into much detail as there are already some great posts out there on the subject. I still feel like CSS itself is a bit of a broken solution, although I can’t articulate why or what would be a better option.
The blog post How Not To Sort By Average Rating continually pops up and got me thinking about how we currently implement sort by rating. We currently use spree_reviews for capturing ratings and it takes a very simplistic approach to storing the average rating for a product:
|
1 2 3 |
self[:avg_rating] = reviews.approved.sum(:rating).to_f / reviews_count |
This exact scenario is mentioned in the blog post above:
Why it is wrong: Average rating works fine if you always have a ton of ratings, but suppose item 1 has 2 positive ratings and 0 negative ratings. Suppose item 2 has 100 positive ratings and 1 negative rating. This algorithm puts item two (tons of positive ratings) below item one (very few positive ratings). WRONG.
A better solution is using a Bayesian estimate which actually takes the number of reviews into consideration. This is how IMDB currently create their top 250 movie list:
weighted rating (WR) = (v ÷ (v+m)) × R + (m ÷ (v+m)) × C
where:
* R = average for the movie (mean) = (Rating)
* v = number of votes for the movie = (votes)
* m = minimum votes required to be listed in the Top 250 (currently 1300)
* C = the mean vote across the whole report (currently 6.8) for the Top 250, only votes from regular voters are considered.
With that, it’s fairly simple to approximate with spree_reviews. Just be sure to recalculate all your product ratings.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
Spree::Product.class_eval do def recalculate_rating reviews_count = self.reviews.reload.approved.count self.reviews_count = reviews_count if reviews_count > 0 r = reviews.approved.average(:rating).to_f v = reviews.approved.count.to_f m = Spree::Review.approved.count.to_f c = Spree::Review.approved.average(:rating).to_f self.avg_rating = (v / (v+m)) * r + (m / (v+m)) * c else self.avg_rating = 0 end self.save end end |
As we mature and become better developers there’s a funny case of code we previously wrote taking on a certain amount of technical debt purely because we have more experience and knowledge on how to tackle the same problems. We’ve all been there, having gone back to look at code we thought was great at the time to only wonder what the hell we were thinking, or gone back to reduce a long method to a single line. Technical debt is inevitable if we continually seek to improve our skills.
On almost every single project I’ve worked on, hard deadlines have nearly always been the cause of any stress or frustration that arises. One day you’re asked to make rough estimates and then next thing you know they become pegged to a date in the future that you must meet at all cost (But you said you think it would only take X days!). Even worse is when someone non-technical makes the estimates for you and passes them down from on high (Look, this is the all the time we have, I’m sure you’ll be fine!).
Why do we still insist on having hard deadlines? Yeah I know, we asked for more features but now the project is “late” so you’ve failed to do your job. Yet, if the deadline wasn’t concrete, the project would have more features then initially scoped and delivered in a timely fashion, you’re a success!
New features are always requested, changes are always wanted and bugs will always be found. If everyone just accepted (understood) that writing software isn’t exact science then we’d all have a lot less stress to deal with and we can stop feeling like a failure for not meeting that pie-in-the-sky deadline.
