rondy

{
	"bold_folder_labels": true,
	"caret_style": "blink",
	"color_scheme": "Packages/One Dark Color Scheme/One Dark.tmTheme",
	"ensure_newline_at_eof_on_save": true,
	"folder_exclude_patterns":
	[
		"tmp",
		".git"
	],

rondy

class Hash
  def self.to_ostruct(nested_hash_object)
    require 'json'
    require 'ostruct'

    JSON.parse(nested_hash_object.to_json, object_class: OpenStruct)
  end

  def to_ostruct
    self.class.to_ostruct(self)

rondy

Deleted tweets for rjs

The list below includes 3098 deleted tweets by rjs.

There are also 2 tweets that are indicated as not currently deleted by the Twitter API that have been scraped from pages of deleted tweets (as replies, etc.). These possibly undeleted tweets are included for context and are indicated by a (live) link.

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

rondy

Organização de testes de aceitação

Sabemos que testes de aceitação (ou "feature tests", no linguajar do Rspec) são os testes mais próximos da especificação que é projetada entre developers, analistas de negócios, stakeholders etc. No paradigma ágil, esses testes deveriam refletir os critérios de aceite definidos em uma user story (aqui, sem entrar no mérito da pirâmide de testes).

Há uma questão que parece ser recorrente durante o desenvolvimento desses testes. Como organizamos os arquivos correspondentes a esses testes?

Eis algumas dúvidas que podem surgir:

• A localização física e o nome dos arquivos deveriam refletir a organização física ou as capabilities do software? Ex:

rondy

Rails exception handling

• http://railscasts.com/episodes/53-handling-exceptions-revised?view=asciicast
• http://code.tutsplus.com/articles/writing-robust-web-applications-the-lost-art-of-exception-handling--net-36395
• http://blog.siami.fr/diving-in-rails-exceptions-handling
• http://rubyjunky.com/never-check-for-an-error-you-dont-know-how-to-handle.html
• http://www.railsonmaui.com/blog/2013/05/08/strategies-for-rails-logging-and-error-handling/
• http://www.monkeyandcrow.com/blog/reading_rails_handling_exceptions/

Rails internals

rondy

Functional objects on Ruby programming language

Goals

• Less questions asked. E.g:
  • How should I name my objects that carry behavior? They're nouns or verbs?
  • Should I expose attr_readers/writers/accessors?
  • What kind of input should it receive from constructor/initializers? And what about methods?
  • https://hackernoon.com/api-design-temporal-coupling-2c1687173c7c
• More consistent style among classes definitions.

rondy

Queueing Theory references

General content

http://www.shmula.com/queueing-theory/
http://ferd.ca/queues-don-t-fix-overload.html
https://news.ycombinator.com/item?id=8632043
https://thetechsolo.wordpress.com/2015/01/25/queueing-theory-explained/
http://people.revoledu.com/kardi/tutorial/Queuing/index.html
http://setosa.io/blog/2014/09/02/gridlock/index.html

rondy

Requests specs x controller specs

Despite of they feel to be almost the same, there is a subtle difference between them: In request specs, you can exercise the full stack of a HTTP request (from routing to the view layer, so to speak).

Request specs also allows you to access more than one endpoint at a time, so you are able to test a whole scenario’s flow, whereas in controller specs you can exercise only one endpoint per test case (i.e., a single controller’s action).

# request spec
specify do
 get '/my-first/enpoint'

rondy

DCI clipping

MVC was meant for reflecting the end user’s mental model but it still makes it too easy to hide the intentions of your program in your code.

• It’s hard to find bugs in own code
• It’s fun to find bugs in other people’s code
• I learn from reviewer’s comments
• Reviewer learns by reading my cod

Code must be Chunkable! Readable!