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.

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,

	from calc import Calc
	from plan import Plan
	from datetime import datetime
	….
	class OurTrialPlan(Plan):
	def __init__(self, start_date, end_date, usage, extra=None):
	super(OurTrialPlan, self).__init__()
	self.calc = Calc(start_date, usage)
	self._extra = extra if type(extra)==dict else {}
	def calculate(self):
	….
	add(10, 'customer charges')
	# OFF-PEAK
	usage = for_month_of(['Jan', 'Feb', 'Oct'])
	cost, tier_rate = slab_wise_tariff( usage, no_change_rates)
	add( cost, 'no_change', rate=tier_rate)
	# KU OFF-PEAK
	usage = for_month_of(['Mar', 'Apr', 'May', 'Nov', 'Dec']) and during('10pm','6am')
	add( usage*0.0265, 'ke_flat_rate', rate=0.0265)
	# KU ON-PEAK
	usage = for_month_of(['Mar', 'Apr', 'May', 'Nov', 'Dec']) and during('6am','10pm')
	cost, tier_rate = slab_wise_tariff( usage, ke_base_rates)
	add( cost, 'ke_base_rates', rate=tier_rate)
	cost, tier_rate = slab_tariff( usage, ke_surcharge)
	add( cost, 'ke_surcharge', rate=tier_rate)
	…..
	return tariff()

view raw

TrialPlan.py

hosted with ❤ by GitHub

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.

Advertisement