Pun Intended?
A fire can’t keep burning without fuel, and profits are the fuel for business.
High Notes // Thoughts on programming languages, software development, entrepreneurship and any other things that I find interesting.
High Notes // Thoughts on programming languages, software development, entrepreneurship and any other things that I find interesting.
A fire can’t keep burning without fuel, and profits are the fuel for business.
It has come to my attention the amount of bashing that Software Engineering has taken lately. Software Engineering has been described as something that doesn't work and as a waste of resources. Well, I don't think that's always the case and I will try to explain why.
As an international student, I've gone to different orientations. Most of these orientations are boring, but during one of the sessions I saw a chart that was interesting:
That's windows 7 running on vmware fusion. Compare the font sizes of the menus. OS X has larger fonts, it makes sense you have to click on them. WIndows tries to be consistent and use the same font size for menus, icons, and address bars. OS X focuses on what's easier for the user. Icon labels and windows titles have a smaller font than menu bars. Again it makes sense, you don't have to click on the labels.
Sometimes it's better to drop consistency in favor of usability.
We know you love Basecamp; and we know that having to switch constantly between Burndown and Basecamp can be time consuming. For this reason we recently added automatic daily synchronizations. Now you can configure a time of the day in which you want Burndown to synchronize with Basecamp. You don't require anymore to manually synchronize your charts, the daily synchronization will take care of that.
Continuing with the usability improvements; today we're excited to introduce another feature: "Basecamp Message Posting". Now you can get your burndown chart posted as a message into your Basecamp project. This is how a posted chart will look inside Basecamp:
Basecamp message posting occurs right after your daily synchronization. You can customize if you want your burndown charts posted daily, weekly or at the end of an iteration. You can also disable the message posting. To configure this new feature check your settings tab.
I hope you find these new features as useful as we have!I built a parser a few days ago using treetop. Treetop is an awesome ruby gem for writing parsers in ruby. The syntax is very clean and elegant, and you don't need to handle countless auto-generated files. Treetop grabs the grammar file on the fly and automagically loads the classes that you need. Pretty neat.
Once you parse text with your parser, treetop returns to you a syntactical tree. To avoid navigating through the syntactical tree, treetops allows you to add methods to your grammar. You can then call these methods in the syntactical tree. Here's an excerpt of the grammar I'm working on:
grammar RepositoryProtocol
rule message
credential / response / request / reply / challenge
{
def node_type
"message"
end
}
end
rule credential
credential_hdr public_key certificates credential_end
{
def pk
public_key.data
end
def certs
certificates.certs
end
def node_type
"credential"
end
}
end
# obviously more stuff goes down here...
end
Now lets talk about the dark side of this tool. There are two problems that I found while using it:
1- Lack of documentation: You can find pretty simplistic examples of grammars in the tools homepage and its github repository. Unfortunately if you need something more complex then a calculator, you're pretty much on yourself. If you google for a while you will find some more complex grammars written out there, but the truth is that the learning curve is a bit steep. For instance it took me quite a while to realize that the syntactical nodes only provide two methods to query a node: elements (an array of child nodes) and text_value (the text contained by the node). Even at this point I'm still not 100% sure if these are the only methods available. Also, if your rule is very simplistic (I mean it lacks or's, *'s, +'s, etc...) , then treetop will add methods with the same name as your grammar rule sons.
2- If you name a rule as something that treetop uses internally you're screwed. This sucks really. There's no message, no list of reserved words, no nothing. So if a rule doesn't work for any logical reason, try renaming it.
3- Nodes don't have a way to identify themselves. There's no node_type method to call to figure out what you're navigating in. If you really need to do that, then you'll have to manually add a node_type method to each rule.
4- No easy way to ignore white spaces. You have to provide a rule in your grammar to handle white spaces, tabs, \r's and \n's.
5- And finally, this problem really took me a while to figure it out. Treetop doesn't really construct the syntactical tree following your grammar literally. Take for example the following rules:
rule clause
implication / single_atom
{
def import(rsa_key)
internal_import(rsa_key)
end
def node_type
"clause"
end
}
end
rule single_atom
literal "."
{
def internal_import(rsa_key)
"#{literal.import(rsa_key)}."
end
def imported_clause?
literal.imported_clause?
end
def node_type
"single_atom"
end
}
end
rule implication
literal ":-" literal other_literals "."
{
def import(rsa_key)
elements.inject("") do |imported_string, e|
imported_string << if e.respond_to? "import"
e.import(rsa_key)
else
e.text_value
end
end
end
def node_type
"implication"
end
}
end
rule other_literals
("," literal)*
{
def import(rsa_key)
elements.inject("") do |imported_clause, e|
imported_clause << ",#{e.elements.last.import(rsa_key)}"
end
end
}
end
rule literal
( "says(" iden "," predicate ")" space ) / predicate
{
def import(rsa_key)
"says(#{rsa_key}, #{text_value})"
end
def node_type
"literal"
end
}
end
Following the grammar of the previous example I would expect the following to be the way in which the syntactical tree for an implication cause to be generated:
But instead I get a tree like this one:
Somehow treetops decides that clause and implication should be the same node and adds some methods of clause to the tree and others from implication. For that reason I use the strange import_internal for some paths, and on others I call import directly. So don't expect the syntactical tree to be an exact representation of your grammar, treetop might be trying some tree optimizations I guess.
Even with all it's problems I sincerely consider this tool much more intuitive than Antler. The syntax is clean and if you don't try to make fancy tricks like making a language translator you should be safe. So if you need a parser on your next ruby project make sure to give treetop a try.
I haven't been posting as much as I would like lately on this blog. Graduate school is keeping me pretty busy lately. Right now I'm taking a Computer Security course that's taking more time from me then what I would really like to. Although at this point I'm feeling a bit regretful, I've been doing some cool stuff lately. From code injections on broken C applications to exploit buffer overflows, remote attacks to web servers, using clusters to break passwords by brute force, up to using prolog for weird ways of security policy definition.
I've also started my final project. I picked up to make a solution for a problem I had while integrating a rails application to a ActiveMQ. You see, in corporate software, there are these things they call "Enterprise Integration Servers". These things are like the key part of the SOA architecture. Although I'm not a big fan of SOA, I can see that there's a lot of value in the so called Enterprise Integration patterns. These patterns are well defined ways for applications to communicate between each other. In the rails side of the world, you communicate between applications using REST. That works great, but when you need to decouple one application from another (specifically the application that sends the resource), or you need to make some fancy sort of queueing, you end up repeating yourself. Sure, you can use ActiveMQ, and using the wonderful ActiveMessaging plugin, but if you're like me, you will not like the idea of having to run this Java server. REST is awesome, rails applications should not rely on STOMP, JMS or other weird things to do their job.
So my final project will be a RESTful messaging server that will implement the design patterns that are described here. I already build a prototype using rails and the delayed_job pattern. I'll be posting more about this project later on.
Anyways, as the old saying says, "don't let school get in the way of your education". I'm gonna try to keep posting more often...
