Is this Spaghetti code?
Doer is not a particularly expressive name. Sure, the class does something -- but what class doesn't? Your impulse to name the class Calendar is definitely on target. There are a few other naming things that are not according to Ruby style guidelines; you should avoid CamelCasing your method names -- for instance, makeCal should be make_cal and even better something like make! or create! (assuming the class itself is named calendar, saying @calendar.make_calendar is repeating yourself.)

In general, with respect to 'spaghetti' code, the issue is usually that you are not really separating concerns. The problem that Objects are trying to solve is encapsulating responsibility. It destroys any advantage you stand to gain to put all your functionality into one place. Object-oriented programming involves modularity and encapsulation -- naming a class Doer might indicate some weaknesses in terms of really grokking the paradigm. Consider studying some actual web application source code and see how concerns are separated and handled at an appropriate level of abstraction.

On that last point, one good rule of thumb is that code which is 'nearby' should be operating at roughly the same level of abstraction. Try to identify different concerns and modularize them -- make them 'loosely coupled' to one another. You might make a class which handles the business logic of padding and packing the string stuff, and separate the 'pure' calendar logic into a different class altogether; your application would then just have to 'glue' the two capabilities together.