Okcal is a project mainly written in ..., it's free.
Calendar for OK.rb code thingy
OK.rb Code Contest
irb example:
cal = OKCal.new cal.new_event('daily','test1','20090215') cal.new_event('daily','test2','20090215', {'stop' => '2009-03-18'}) cal.new_event('weekly','test3','20090215',{'stop' => '2009-03-18', 'frequency' => 3}) cal.new_event('weekly','test4','20090215',{'stop' => '2009-03-18', 'frequency' => ['Monday','Thursday']}) cal.new_event('monthly','test5','20090215',{'stop' => '2009-12-12', 'frequency' => 0}) cal.new_event('monthly','test6','2009-12-18',{'stop' => '2010-12-18', 'frequency' => 'last', 'day' => 'Tuesday'}) cal.new_event('yearly','test7','2009-12-18',{'stop' => '2018-12-18'}) cal.new_event('yearly','test8','2009-12-18')
Directions:
Grant and Brian have agreed to do a little code challenge experiment
for us at the February meeting. This is for the fun and education of
us all. Thanks guys!
Below are the details of their challenge for them to see and for those
of us who wish to follow along.
Tim is going to give a talk for the other half of the meeting, showing
off a few of his favorite libraries.
As you can see, it's shaping up to be a great meeting!
James Edward Gray II
The contestants will complete a simple calendar application with just
two abilities: users should be able to enter events and see what
events will occur on a given day. The primary challenge comes from
the fact that the code is expected to handle multiple types of events.
The code you provide really only has to do two things: accept new
event entries and provide a way to list all events occurring on a
given day. No judging will be done on the interface, so you are free
to provide a nice interface for these two action or just build methods
to call in IRb or a testing environment. Whatever is easiest for you
is fine.
No judging will be done on tests, documentation, or any other
ancillary assets to the code itself. However, you will be judged on
how easy it is for others to understand your code as outlined below
and these items may help with that.
You also do not need to worry about the data stressing your code.
You're program doesn't need to handle so much data that it can't all
be stored in memory and event fields will be consistently sane. No
dates will be used that are outside a two year range centered on
today, so you needn't worry about calendar changes or the resolution
of Ruby's built in Time class. You just need to build the core
functionality of the problem.
The main challenge is that your calendar is expected to support
multiple types of events. Users need to be able to create any or all
of the types listed below and searches must check all known events
returning all events that will fall on a given day, regardless of type.
Each event type can have different fields and the types share some
fields. Some fields are optional and some have defaults you need to
account for.
All events have a unique name (a String) and a start date and time (a
Time) that are always provided. All events can also have an end date
and time (also a Time), but this field can also be left nil to
indicate that an event is ongoing and does not end.
You can mostly ignore the time portion of all dates and times for the
purposes of this exercise. We're only interested in which events
appear on a given day and the times don't play into that.
Beyond that, the event types differ as follows:
The spirit of this contest is totally for fun and there will be no
official winner or loser. However, we do have some criteria upon
which entries will be considered, just for friendly bragging rights!
The contestants are expected to make their solutions publicly
available by posting them to the mailing list two days before the
February meeting. That means solutions should be posted on February
10th by 6:30 PM.
At the meeting, each of you will explain the other contestant's
code. You are expected to highlight how it works and point out
things you like about the solution. You will be judged on how well
you understand the code you are showing and on how easy your code was
to understand.
If you notice any problems with the code, like edge case searches it
wouldn't get right, feel free to point those out as well. This shows
an even greater understanding of the code on your part.
--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Oklahoma Ruby Users Group" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/okrb?hl=en -~----------~----~----~----~------~----~------~--~---