{% show_simple_captcha_tag %}

Showing simple captcha in liquid template

Advertisements

rspec STDOUT

I happened to write some rspec for one ruby program which was accepting some input text in some form, and then it was expected to print the output to the console, or perhaps I did not want to separate the logic of printing. Anyways, that made me expect rspec should check the console output of my program, and after some googling(thanks to many rubyist) I got to work the following

Wow, I liked it.

And the spec_helper made it for me

activeadmin cool tweaks

tweak 1: Make some column quick-editable on the index list page

1

Ok… so I want to be quickly able to edit few names, here on the same list page, something like below

2

Thats simply great!

Now it makes me quickly update any name there itself on the list page, <enter> will make it, <escape> will ignore it, and <tab> will move to the next one. awesome.

And to make it work I just need to have one line of code change

All I need to say is `editable_test_column`, and its done.

And here how it works, you will need to define a couple of things

You need to define editable_text_column, this you could place inside app/admin/lib/

Then you will need to add some javascript …

and some css stuff

Thats it.

Next, I would love to quickly alter article type say having a dropdown there to save my time

tweak 2: quick editable dropdowns on list page

6

Ohh, now this is again great!   … no? It actually updates the article type on value change. nice.

Let see the code behind

and to define `column_select`

CustomHelper is one of my helper modules that really helps me render dropdown the way I need, and provides me some nice options, one may choose to use the default rails select helpers

Then you need some javascript

done.

I do have worked out several more tweaks like toggle button for boolean column, show/hide columns on the list page, auto-populate/suggest feature for string filters, one can make use ActiveAdmin icons too, then for one of my requirements I have set up the whole custom header and a dozens of custom pages. I would easily say that ActiveAdmin is just simple and awesome, one can really customize it to the extreme, the code structure will allow you to imagine and implement a number of custom scenarios.

DSL approach made it really simple

How much watts we do consume per cycle? Have we joined any of the green innovations like for instance green button. It would be great to know how much watts my house consumed this cycle, will I be able to reduce it, any one out there to help me reduce it. I have so many appliances running at home and I do have a smart meter measuring how much has been consumed. Would you also want to know how does meter measure your watts consumed, and how smart meters provide data for further calculation of your electricity bills.




There are several initiatives taking place in US, PlotWatt, FirstFuel and more, and they help you know your own detailed energy usage, along with other features like calculations, helping you out choosing right pricing plan, giving you several suggestions on how could you reduce your consumption and electricity bills.

Okeh, so this was a quick about Green Button.

Working on one of such initiatives, I came across to define a solution that will enable users to see what electricity bill they would end up paying if they apply some different pricing plan, hence ability to apply different pricing plans against the data consumed for the current or past cycles and being able to compare plans. Rather this would actually help utilities defining their trial plans.

Being rubiest for now more than 5 years, it immediately struck me about having a nice ruby DSL for this one, which could be easier to extend for new rules or sub-requirements. And this was a too much of excitement for me. Writing DSL gives you opportunities to play around ruby mixins, better modeling your classes, modules, beautifully engaging them with each other to work for us and present a nice output.

form

But there was a bad news for me, team decided to do this in python :(  … though still I am to design and develop it.

Not having much exposure to python, having my ruby design plan ready on my mind, I started looking similar python capabilities, parsing, meta-programming, DSL models and more, team as well decided an approach that no need admin to define plans on the fly( like one above), but we could have some fixed plans defined, that actually saved my efforts.

Following is one example of one of those plans we have,

And we do have several such plans and we could define more, simply focusing on plan rules. The guts have been encapsulated using classes Plan and Calc. Calc helps to collect, compute usage for the specified period, while Plan provides semantics  around.

I did enjoy python scripting a lot, python looks to me as a raw scripting platform where ruby as a very nice, user-friendly scripting platform.

dealing with concerns

Taking care of concerns, my views are

They are meant not to have large/GOD classes

They are not specific to ActiveRecord

They are there to help us out find out dependencies easier

They should not be dependent on each other, if module A has concern :b, then there should exist paths “root/a.rb” and “/root/a/b.rb“. Though this we ourself have to make sure about concerns path by writing additional code at initialization

I always willing to write clean and neat code, and have end up maintaining my concerns the following ways

  1. Reopening Class
  2. Include Module
  3. Extend ActiveSupport::Concern

I do have one doubt though, out of 3 approaches, which one is good for faster execution?

mailto:jenkins,subject:test case1, case2 on http://staging.site.com

mailto:jenkins,subject:test case1, case2 on http://staging.site.com

So this is something we thought of

– email Jenkins
– to run one or more jobs
– against one of our deployed staging apps(given base_url)

We wrote a mail_watcher.rb, which periodically reads such emails, and rewrite <JENKINS_CHECKS_DIR>/<test_case_name>.checks files adding parameters to be passed on to the test case. In this case it is BASE_URL=. And all we know that we could make Jenkins

1. watch files getting modified
2. use file contents(key=val), as paramters further to be used or passed on to the job exec

Ohh, wait, I did not know how could Jenkins read parameters from a given key=val file and pass it on further. We actaully wrote another shell script which runs as the first step of every job and reads the testcase_name.checks file and set ENV variables like for example BASE_URL.

So in case of subject:test testcase1 on http://mysite.com

– mail watcher will write testcase1.checks file with BASE_URL=http://mysite.com
– shell script will set ENV variable BASE_URL=http://mysite.com


Following is the mail watcher that we simply run to be able to get Jenkins job triggered.

Now any of us teammates, can anytime send an email and get a test case executed. In addition we are as well generating a detailed report email for each job-run that gets published on a Google group. We do have our own custom, half-baked, reporting mechanism(ruby code), which we want to compile the job-execution-report email for each testcase/job executed.

Example reports

subject: testcase1 failed.
body: <Jenkins console output>

subject: rspec 231 passed, 2 failed.
body: <Jenkins console output>

reading huge xml in ruby

Dealing with huge xml? say of size 400 MB or more than a GB. No worries, Nokogiri::XML::Reader is there for your help. But let me tell you it takes a while before you understand it and start using it. Needs to understand types of elements, and when to read value and and when to read attributes. However I have went over it and tried defining my own module which now simplifies it.

Your large xml doc must be having thousands of records, and you may or may not know the structure of record. This module will help you easily read your records, its elements, something like this below …

hey_my_module
  take_this_xml
  and look_for_these_elements
  let_me_know_if_you_find_any_of_them

…hence

HugeXML.read xml, elements_lookup do |element|
  # => element{ :name, :value, :attributes}
end

so simple right? wanna check it out… here it is  => github.com/amolpujari/reading-huge-xml