YurkoHoshko

One-shot prompt with Ollama

Mix.install(
  [:ollama, :kino]
)

Simple one-shot chat :)

rodrigues

💶 Euro Exchange Rates History

Mix.install([
  {:briefly, "~> 0.4.1"},
  {:req, "~> 0.3.10"},

adolfont

Brazilians interviewed by non-Brazilian software engineering podcasts/YouTube channels in English

2020

• Changelog Backstage – Episode #14 - Experimenting with Elixir Radar featuring Hugo Baraúna
• Thinking Elixir #015 Inside Elixir Radar with Hugo Baraúna
• The Changelog – Episode #402 - What's next for José Valim and Elixir? from acquihire to helping teams run Elixir in production
• Elixir Mix EMx 106: Elixir Education with Adolfo Neto
• Elixir Mix EMx 095: Adopting Elixir at FindHotel with Fernando Hamasaki de Amorim

Sanabria

(* Note 1: The 1 after menu bar may need to be changed to 2 when using multiple monitors *)
(* Note 2: For 10.11 and newer “NotificationCenter” is now spelled “Notification Center”*)

tell application "System Events"
	tell application process "SystemUIServer"
		try
			if exists menu bar item "Notification Center, Do Not Disturb enabled" of menu bar 1 of application process "SystemUIServer" of application "System Events" then
				(* It is disabled *)
				display dialog "Notifications will be turned on" buttons {"Got it"} default button 1
				key down option

rondy

Rondy Sousa (@plataforma.rondy): @brunno.santos, puxando o gancho no papo das descrições de MR, uma coisa que a gente costuma fazer é manter a descrição do MR no commit principal (title+descripton do MR batendo com o do commit).

A vantagem é que a motivação/propósito do MR ("pois o bundle da product já tem esse link salvo no banco") fica documentada no histórico do controle de versão (e agnóstico da plataforma de code review).

Brunno dos Santos (@brunno.santos): @plataforma.rondy interessante esse esquema que vcs usam de colocar a descrição no commit, mas o problema é definir qual é o commit principal, as vezes nem temos um. Como vocês lidam com isso?

Rondy Sousa (@plataforma.rondy): @brunno.santos, A gente faz squash dos commits antes de fazer merge no master, com o commit resultante recebendo o título + descrição do MR.

Na grande maioria das vezes, commits separados representam (ou deveriam representar) apenas "snapshots" de work-in-progress do MR. No momento do merge, eles acabam não acre

pixeltrix

require 'benchmark/ips'
require "action_controller/railtie"

class BlogApplication < Rails::Application
  config.eager_load = false
  config.root = File.dirname(__FILE__)
  config.session_store :cookie_store, key: 'session'
  config.secret_key_base = 'secret'
end

lucasmazza

Devise / Warden Tagged logging

I wrote a middleware (actually two, but they do the same with different implementations) that logs information about signed in scopes in a Rails + Devise application. The solution works with multiple logins (like having a person logged both as an Admin and a User). I tested against Rails 4 and Devise HEAD, but it should work fine in any Rails 3 application.

This solution doesn't use the log_tags configuration option since it isn't very helpful when you need to retrieve information stored in cookies/session. That information isn't 'ready' when the Rails::Rack::Logger is executed, since it happens way down in the middleware chain.

Add one of the following implementations to your application load path and use the following configuration to add the middleware to your application stack:

# application.rb

SlexAxton

gifify() {
  if [[ -n "$1" ]]; then
    if [[ $2 == '--good' ]]; then
      ffmpeg -i $1 -r 10 -vcodec png out-static-%05d.png
      time convert -verbose +dither -layers Optimize -resize 600x600\> out-static*.png  GIF:- | gifsicle --colors 128 --delay=5 --loop --optimize=3 --multifile - > $1.gif
      rm out-static*.png
    else
      ffmpeg -i $1 -s 600x400 -pix_fmt rgb24 -r 10 -f gif - | gifsicle --optimize=3 --delay=3 > $1.gif
    fi
  else

brianstorti

#Practical Object Oriented Design in Ruby

Design that anticipate specific future requirements almost always end badly.
Practical design does not anticipate what will happen to your application, it merely accepts that something
will and that, in the present, you cannot know what. It does not guess the future; it preserves your options for accommodating the future.
It doesn't choose; it leaves you room to move.
The purpose of design it to allow you to do it later and its primary goal is to reduce the cost of change.

Design is more the art of preserving changeability than it is the act of achieving perfection.

rtomayko

# The new git-scm.com site includes man pages designed for pleasant viewing in a web browser:
#
# http://git-scm.com/docs
#
# The commands below can be used to configure git to open these pages when
# using `git help -w <command>' from the command line. Just enter the config
# commands in your shell to modify your ~/.gitconfig file.

# Create a new browser command and configure help -w to use it.
git config --global browser.gitscm.cmd "/bin/sh -c 'open http://git-scm.com/docs/\$(basename \$1 .html)' --"