#rgsoc

[tesselproject]

Team 276linesofCode - Rails Girls Summer of Code 2017

Hey all,

It has been a long long ride since February (when we had to write our applications for RGSoC 2017) and it's finally July!

This is when we start our Rails Girls Summer of Code (RGSoC) 2017 program, by working and contributing for Tessel. Having seen Tessel as a project in the RGSoC project list of 2017, we were eager to take it up at once since, we felt that through this project we would be able to discover both the horizons - Hardware and Software.

Who are we?

Team 276linesofCode is an amalgamation of all things tech and electronic. The Team comprises Shravika Mittal and Brihi Joshi, a duo from New Delhi, India, in their sophomore year of College at IIIT Delhi. We are a dynamic duo that believes in learning and strengthening concepts while on the way to developing something.

Shravika is an Undergraduate majoring in Computer Science and Engineering. It's been hardly a year since she's got her hands dirty with programming, and it's already a vital part of her daily schedule. She brings out dedication and hard work in the team, excelling in whatever she does.

Brihi is majoring in Electronics and Communication Engineering and loves to mix and fiddle with creativity in code. She brings in the caffeine-induced, late night coding sessions along with fresh experiments in the team.

About our mentor - Kelsey

Kelsey is the team's mentor. She has been at Tessel since its beginning and is a member of the Tessel Project Steering Committee. All of the members of the Steering Committee are very excited to work with our RGSoC team– both to improve internal processes and mentoring capabilities, and to have the benefit of two full-time contributors building on Tessel!

What is RGSoC?

Rails Girls Summer of Code is a three month long award-winning global fellowship program aimed at bringing more diversity into Open Source.

It is about helping introduce newcomers to the world of programming and further expand their knowledge and skills, by contributing to a worthwhile Open Source project. The focus is not on producing highly sophisticated code, but rather participants learning transferable skills from their project work. Apart from experience in large-scale projects, RGSoC also inculcates community building by introducing its scholars to people who maintain these projects and other members of the community involved in it.

The RGSoC team structure goes like this : 1. The Students - A pair of Students who are enthusiastic to work on a chosen Open Source Project. 1. A Project Mentor - Usually an active contributor in the Open Source Project that is chosen. He/She is responsible for guiding the students in the project related tasks, features that are to be added and overall development of the project. 1. The Project Coaches - They are selected by the students during the time of the application and might be local (present in the same location as the students) or remote. They usually help the students in handling technical difficulties throughout the course of the program. 1. The Project Supervisor - They are the representatives of the RGSoC organisational team and guide the rest of the team with the procedures of the program.

RGSoC has both the sides - technical as well as social. Apart from working on the project, we even need to get involved in social meets such as a team call with the project supervisor, maintaining daily logs about what was achieved and what challenges we encountered that day, writing blog posts about our experiences etc.

This year, 20 teams were selected among which, 16 are Sponsored teams (We are one of them :smile:) and 4 are Volunteer teams.

What are we here for?

First and most important of all, to have fun! We are way too excited to start contributing and giving our best to this community.

Before the program started, we went through the Tessel repositories, got our development boards and familiarised ourselves with JavaScript. Soon after the program began, we sent in a few PRs to understand the contribution protocol of Tessel.

Soon as we complete the Tessel tutorials, we would be kicking off with an implementation of the 1-wire protocol in Tessel, which requires a lot of reading and working from our end. Then we are looking forward to move to a real world project, which can be solved using Tessel.

Before the beginning of RGSoC 17, we had formulated a plan to work on a project called Humanoid Arm Project (HAP). We would like to continue our work on this and bring it into realisation for solving some day to day problems using technology.

Having experienced a few IoT developmemt boards before, we cannot wait to delve deeper into the various functionalities and modules that Tessel has got to offer us. Also, Rust and JavaScript is a new experience for us. This would be the first time both of us are contributing to an Open Source project and we would like to learn the most we can from it.

We really hope RGSoC would help us transition from Team 276linesofCode to Tesselators so that we can be a part of this community even after RGSoC is over.

Here's to an exciting summer! :tada: :confetti_ball:

[trudemaethien]

AO3 First Lines

rules: post the first lines of your last 10 fics posted to AO3. if you have less than 10 fics posted, post the first lines of all your fics. (I have omitted some works for various reasons.)

open-tag from @nottonyharrison got me started and tag from @the-bees-patella got my ass in gear to finish, i just had to add the newest and delete the oldest 😊

“My Reserve Training Corps cadets are highly trained and perform on the same level as all you prestigious Republic Military Academy cadets, so if you think your education or credentials set you above, get that idea out of your head right now. We’re on the same team here, and that means no one gets special treatment.”

“Heyo, look what the tide washed up,” says a smugly cheerful voice Waxer had been worried he might never hear again. He whirls, legs tangling in the rungs of the bar stool in his haste.

At the unprecedented ID code on the incoming call, Kix sits up straight. “Commander Colt! To what do I owe the honor, sir?”

“Fi,” Ordo’s voice calls, as Fi passes his door, ajar as it usually isn’t. Fi stops in his tracks.

Maze only really came onto his radar after Dha Werda Verda. Ordo had complained about RGSOC obliquely before, generally, as regs or GAR bureaucracy. Jaing always thought it was a damn waste to stick an ARC into an office.

Etain’s feet touched down on Qiiluran soil once again, giving her the disconcerting sensation of homecoming, but a micron out of alignment.

“Lieutenant Law, Execute Order 66.”

Fox’s boot tapped the mosaic floor of the Jedi temple as he dismounted the speeder. All was still, tension strung, visibility low. He couldn’t hear any sounds of violence, so it was a fifty-fifty chance, they were either early enough or far too late.

“Are we going to have a problem here, gentlemen?” General Kenobi asks, looking between the two clone officers with a slight, amused smile.

Down on the lower levels, low enough that people didn’t ask too many questions, but still high enough to support a mostly human and humanoid population, there were places. Not approved, tourist-trap places like 79’s, which the public and all the surface knew about, but places that every brother knew, and plenty more people who knew but wouldn’t flap their lingual anatomy about.

tagging sans coercion: @elthadriel @kaasknot @chemicaljude @ionfusionpunk @hidingaway1995 @coinin

[juuh42dias]

#acerlaptop #stickers #railsgirls #rgsoc #gifts

[olibarnesdevstuff-blog]

Learning Behavior-Driven Development with Ember CLI - part I

This tutorial walks through BDD‘ing a feature with Ember CLI, Mocha and Chai.

I’m writing it as I learn Emberjs, its way of doing things and its toolset, and try to adapt my usual workflow coming from Ruby. It’s meant as an initial guide for the RGSoC team working on Participate. Hopefully this post will be helpful to others learning Ember as well, and even better, invite people to show how they’re doing things themselves in the comments.

The feature I’ll build here in baby-steps will be Posting a New Initiative. In Participate, a user can post proposals for civic initiatives, to which other users can then suggest changes, and then vote on.

This first installment will involve nothing but filling out a simple form with a title and a description, and submitting it. The next installment will add validation checking both fields are filled-in.

As the feature gets incremented - an initiative must have an author and belong to an issue, for instance - new installments will come describing the process of adding them in. At some point I’ll talk about integrating with the separate API backend app.

Setup

Besides Ember CLI, Mocha and Chai, we’ll also use Emblem and EasyForm.

I go through installing all of them on another blog post.

Once you you got them and have generated your app (we’ll assume it’s called ‘post-initiative’ here in the tute), create a new file app/adapters/application.js and add this line to it:

export default DS.FixtureAdapter.extend();

This defines we’ll be using fixtures, so we don’t need to worry about the backend for now.

Starting with an acceptance test

Let’s start with a test that drives the interface, describing user interactions and expectations first, then implement these by letting test errors be the guide as much as possible.

Create a file named posting-an-initiative-test.js under tests/acceptance.

import startApp from 'post-initiative/tests/helpers/start-app'; import Resolver from 'post-initiative/tests/helpers/resolver'; var App; suite('Posting an initiative', { setup: function(){ App = startApp(); }, teardown: function() { Ember.run(App, 'destroy'); } });

Let’s add a test for a link to create a new initiative:

test('Successfully', function(){ visit('/').then(function() { click( $("a:contains('Start a new initiative')") ).then(function() { expect(currentPath()).to.equal('/initiatives/new'); }); }); });

And, from the command line, run ember test:

➜ post-initiative git:(simple-new-initiative) ✗ ember test version: 0.0.37 Built project successfully. Stored in "/Users/work/Projects/post-initiative/tmp/class-tests_dist-Bv3r6aYr.tmp". not ok 1 PhantomJS 1.9 - Posting an initiative Successfully --- message: > Error: Element [object Object] not found.

The key here is the message output. The opaque error means Jquery hasn’t found the link.

And understandably so, since it doesn’t exist yet.

Link to new initiative

Let’s implement it by adding it to application.emblem, under app/templates.

h2 Participate App #menu = link-to 'initiatives.new' | Start a new initiative =outlet

Run ember test again and you’ll get a new message:

message: > Assertion Failed: The attempt to link-to route 'initiatives.new' failed. The router did not find 'initiatives.new' in its possible routes: 'loading', 'error', 'index', 'application'

Route

In the router (app/router.js), let’s add a route to a new initiative resource:

Router.map(function() { this.resource('initiatives', function() { this.route('new'); }); });

Tests should pass now.

1..1 # tests 1 # pass 1 # fail 0 # ok

This is the basic flow. Let’s add another expectation:

Adding the template and form for the new initiative

After clicking the link, the user should be able to fill in a title for the initiative. Add this line to the test

fillIn('div.title input', 'Public health clinic');

So it now looks like this:

test('Successfully', function(){ visit('/').then(function() { click( $("a:contains('Start a new initiative')") ).then(function() { expect(currentURL()).to.equal('/initiatives/new'); fillIn('div.initiative div.title input', 'Public health clinic') }); }); });

Run the test again:

message: > Error: Element div.initiative div.title input not found.

To satisfy this, let’s create a template, and in it our form:

Create a directory initiatives under app/templates, and then add a file called new.emblem.

Paste the following in it:

form-for model = input title

Run the tests again, and they should pass.

Let’s add the remainder of the form-filling steps in our test:

visit('/').then(function() { click( $("a:contains('Start a new initiative')") ).then(function() { expect(currentURL()).to.equal('/initiatives/new'); fillIn('div.title input', 'Public health clinic'); fillIn('div.description textarea', 'Allocate compensation money to create a local public health clinic'); click('form input[type=submit]'); });

Running the tests again will give us:

message: > Error: Element div.description textarea not found.

Add the next input field and the save button to the form:

form-for controller = input title = input description as="text" = submit

The tests should now pass again.

Of course, submitting the form doesn’t do anything yet :)

Submitting the form

So what would a user expect to see after submitting the form. Likely she’ll:

Expect to see the url change

Expect to see the new initiative’s content so she can be sure it went through correctly.

She would also expect a confirmation message, but testing that is a little more involved from what I could find so far. So I’m leaving it for a later installment.

Let’s add these expectations within a then() function chained to click():

click('form input[type=submit]').then(function() { expect(currentPath()).to.equal('initiatives.show'); expect(find('.title').text()).to.equal('Public health clinic'); expect(find('.description').text()).to.equal('Allocate compensation money to create a local public health clinic'); });

then() returns a “promise”, and writing the expectations in a callback passed to it means they’ll get run once click() is done and the resulting rendering is finished. Promises can be a confusing concept at first (I’m still grokking them), but powerful - they let us not worry about all the issues coming from async events.

Run the tests:

message: > AssertionError: expected 'initiatives.new' to equal 'initiatives.show'

To satisfy this and get to the next error, we’ll need to take a few steps, inherent to how Ember wires routes and data being passed around. The errors I got when going through each of the steps weren’t very informative, and I got things working by trial & error & lot of googling and asking things on #emberjs. So I’m pragmatically breaking tdd here and just wiring enough to get to a useful error.

(For more info on what these steps are about, read the Ember guides on routing and controllers, and this thread on Discuss, which clarified things a lot for me. Ember’s architecture is still a moving target.)

First, let’s add this route handler for app/routes/initiatives/new.js:

import Ember from 'ember'; var InitiativesNewRoute = Ember.Route.extend({ model: function() { return this.store.createRecord('initiative'); }, actions: { submit: function() { this.transitionTo('initiatives.show'); } } }); export default InitiativesNewRoute;

And this model definition (app/models/initiative.js) to go with it:

var Initiative = DS.Model.extend({ title: DS.attr('string'), description: DS.attr('string') }); export default Initiative;

Next, update the router (app/router.js) to include a path to /initiatives/show:

Router.map(function() { this.resource('initiatives', function() { this.route('new'); this.route('show'); }); });

And add the corresponding template (app/templates/initiatives/show.emblem). It can be empty for now.

Run the tests and we’ll get

AssertionError: expected '' to equal 'Public health clinic'

Which means that we got the route transition to work, and are now looking at this test:

expect(find('.title').text()).to.equal('Public health clinic');

We made some progress. So far the user can:

navigate to our app’s homepage

click on the link for a new initiative

fill in a form with the title and description for it

submit it

get redirected to the created initiative page.

But there’s no initiative created yet. Let’s tackle this next:

Handling the form submission

Here I’m also going to wire a few things up to get to the next test error.

Let’s update InitiativesNewRoute to handle the submitted params, and then transition to /initiatives/show/:initiative_id

var InitiativesNewRoute = Ember.Route.extend({ model: function(params) { return this.store.createRecord('initiative', params); }, actions: { submit: function() { var _this = this; var initiative = this.get('controller.model'); initiative.save().then(function(model) { _this.transitionTo('initiatives.show', model.get('id')); }); } } });

Update the router to accept the :initiative_id segment:

this.resource('initiatives', function() { this.route('new'); this.route('show', {path: '/:initiative_id'}); });

Create a InitiativesShowRoute (app/routes/initiatives/show.js) to fetch the initiative model:

import Ember from 'ember'; var InitiativesShowRoute = Ember.Route.extend({ model: function(params) { return this.store.find('initiative', params.initiative_id); } }); export default InitiativesShowRoute;

And, finally, a new template for showing the initiative (app/templates/initiatives/show.emblem)

.title h2 model.title .description p model.description

Run the tests and they should pass.

Start up ember-cli’s server by running ember serve, and point your browser to http://localhost:4200/, for a good sanity check. If everything went well, this tiny feature should just work :)

Coming soon: Adding validations

Written with StackEdit.

[newrosies]

Rack Middlewares

Today we learned a lot of new things about Rack and how Rack and Rack middlewares and how everything works internally. Today we studied the source code of Rack::Builder, Rack::Runtime, Rack::ContentLength, Rack::ContentType and Rack::Head.

Have a nice day!!!

Laura & Adriana.

[harinilearnsruby]

Cool things I've learned from other Ruby learners - Part 1

I’ve been following a lot of tumblrs that talk about Ruby, Hacker Schools and Programming bootcamps lately. This has been great for me because I almost always learn something new from them. This is what I learned from “Keep Calm && Program”:

Rails Girls Summer of Code - this is a program that helps Rails Girls students to get into Open Source. This is a big deal because the industry could do with some diversity. It is targeted at ruby beginners & you team up with another Ruby learner, find a mentor and work on open source projects for a few months. What is really awesome about this program is that you actually get paid to learn. What more can you really want? 

I wish I had known about this sooner because this is right up my alley, but I missed the deadline by a day. It’s so frustrating when something like that happens! But anyways, I’m putting this info out here just in case it is of interest to someone else. I’m going to do this during their next cycle :)

[jzeta]

well, that was a good week. muchas gracias @codingzeal @rbates @kentbeck #roguerails #rgsoc

[juuh42dias]

#rgsoc #railsgyn #macbook #cupcake

[highwaytorails]

Day 62 - 27.9.2013 - Fine-tuning (der Feinschliff)

It's our second to last day! How strange! Just think, this time next week we'll be... well... we don't know where... but... we won't be here, that's for sure. 

This morning we started off by looking at our app... gazing at it in all its glory... and wondering what else we should do. We finished off the cron job and rake task yesterday, so we could rip up our second to last index card.

Only one more to go! (and it's basically Carsten's job anyway...)

So we started fine-tuning. We changed the email format a bit so that the email's subject can be set by the user, and also so that they'll be informed as to whether or not their event occurred (which is kind of a big deal...) We also made various aspects of our app more user friendly, and cleaned up the ambiguous terms a bit. (Matching Direction = Forward/Backward.... we assume this makes sense to no one but us). Along the way, some of our tests started failing, but we managed to clean these up in no time. Oh yeeeeeeah.

We also went for lunch with Julius today, our guerrilla coach, and gave him his present! All the RGSoC women in the building signed a mug for him (with fancy porcelain markers) as a thanks for all his hard work and his whiteboard sessions. Thanks so much Julius! We hope to keep learning with you after the summer is over!

Oh, and we deployed to Heroku a couple a times... no biggie. 

Weekly Overview: WE DID ALL THE THINGS! This week was pretty cool, we got to see our app in action, and the rake task and cron job (something we've been talking about for ages) were finally implemented. We were also incredibly distracted applying for jobs, thinking about jobs, asking people to hire us... you know how it is... Speaking of which, please hire us. 

Goals for next week: Don't accidentally delete everything...

And, so we don't forget:

write GitHub ReadMe (gem and app)

fix pagination

release the gem

connect remote side app 

try not to cry :(

[highwaytorails]

Day 49 - 9.9.2013 - Play by Play, Haml, CSS, Client side

This weekend both of us were busy bees: Tam got some CSS beauty done and Susanne introduced Event Girl to Haml. Our first task today therefore was to merge our two awesome branches into our even more awesome master! 

Then we continued with watching an episode of play by play with programming masterminds Corey Haines and Aaron Patterson. In this episode both of them are - just like the two of us - working on an event tracking system. Theirs is almost as good as ours. Good job guys, you're well on your way! While we're watching we tweeted Corey Haines and Aaron Patterson and to our surprise Corey tweeted us back. We believe that our coaches, or rather the entire IT department, are jealous of our new tweeting buddy. 

After we calmed down, we continued working on our index cards. Next up: Creating a Client Side MVC. This feels like the good old days (two months ago) when we were just starting our app. But now we are playing around with Haml and Simple Form as well. 

Another very important thing that happened today: We put up a new link on our blog that is called "HIRE US". It's pretty self-explanatory. Please click on it - and hire us. Thanks!

[newrosies]

Welcome to our Summer!

Hello World!!

We're Laura and Adriana from Barranquilla, Colombia, one of the nine lucky teams accepted into Rails Girls Summer of Code 2013, thanks you so much again for let us to participate in this awesome program :D

We will be working in Conductor project, one of the DHH's little babies since early rails years. We will post more details about our project in other post soon.

We have a great mentor (@guilleiguaran) and a super coach (@robermiranda) who will be supporting us with the project all summer :D.

In this blog we will write all the challenges, successes and learnings during this 3 months of coding.

You can subscribe to our blog via RSS with this link

Enjoy this summer! 

Laura & Adriana 

[tesselproject]

Team 276linesofCode - Rails Girls Summer of Code 2017

A note from Kelsey, mentor for team 275linesofCode:

I loved working with Brihi and Shravika through the summer, and am so happy to see them still commenting and contributing in the Tessel channels, four months after the official close of the summer program.

Rails Girls Summer of Code provided just enough support (including requiring the mentees to find further technical help locally) that I could focus my role on finding the intersection between the project's needs and my team's interests.

It was a pleasure to watch my team dive into challenges, struggle through frustrations, overcome shyness about asking for help, and really grow as contributors to the open source ecosystem. It also helped me to engage better with my own project, and was a wonderful source of energy for the Tessel Project as a whole.

To the other open source projects out there: I strongly recommend becoming a project mentor– this year's deadline is January 28th, so jump in soon!

–Kelsey

In June 2017, none of us had any idea what this journey would be like. RGSoC was the first Summer of Code or any other code mentorship program that we had been a part of. Our eagerness to grasp the most from the program kept us going all through the summer. We gained much more than we had even anticipated.

We both believe that Tessel was the best project that we could have worked on, since it welcomes new contributors in a positive manner that motivates them to give back to the community as much as they can.

Our Work this Summer

As we look back into our two and a half months, RGSoC and Tessel have given us opportunities to explore and grow in all spheres of an open source project. We got our hands dirty with things like documentation, tutorials, code, hardware experiments, talks, presentations and even product design.

We started our summer by exploring version control with GitHub and learning its intricacies. A professional open source project has a very different approach to pull requests and contributions than we were used to. We learned how to send pull requests, how to get them reviewed (trust us, reviews are the real deal for learning), how to squash commits, how to write clean code and clean commit messages, how to branch cloned repositories, and most importantly, how to voice questions and doubts on the issues that we don't understand.

Our Hardware modules were shipped by the Tessel team from the U.S., and we spent some time exploring them. This was the most exciting part: making circuits, seeing the LEDs shimmer, watching the accelerometer come to life, and much more.

After exploring the different repositories in Tessel, we started exploring issues which were "contribution starters", issues that help new contributors get an idea of what Tessel is all about. A lot of the starter issues we took on were listed in the Tessel blog called "This Week in Tessel"; we started completing them one at a time.

We made important tutorial modules for Tessel for their documentation page. This included Fritzing diagrams of the circuits, describing the functionality in layman terms, and writing code which would be easily understood, with the help of the comments. Along with this we started working on "Reach" during the last few weeks of the program.

Apart from all the technical work, we learned about product design and how exactly a product makes its way to the open source domain. We made a draft of something called a Product Requirement Document (PRD) for our proposal of HAP (Humanoid Arm Project) that we had made during our application process.

Challenges

Before RGSoC had started, our mentor, Kelsey had sent us a Plan of Work to follow, which helped us to schedule our tasks. It included the various things we had suggested we would like to work on during our application process. It was a weekly plan with difficulty level slightly increasing every week.

Here are some of the challenges we faced during the program:

One of the tasks we had to accomplish was to implement One-Wire Communication Protocol for Tessel. We worked for our initial few weeks on this issue, but we were not able to get much out of it. This was because we were not able to figure out exactly where to start. We tried mapping the Arduino code to Tessel, but still couldn't succeed.

Since we were beginners in git, sometimes we weren't able to figure out how to squash multiple commits into one for clarity, how to sync the forked branches with the master branch, and many other foibles. In the beginning, we did not even know how to send pull requests for different issues by making separate branches for each.

In the second month of RGSoC, during one of our weekly calls with Kelsey, we were introduced to Reach, which is a module that the Tessel community is currently working on. It requires the ESP32 hardware module. So, we got one for ourselves and started working on it, but got stuck since we were not able to push the Python code to the module. In the end, we were able to figure out the error in our approach with the help of one of our seniors at our University.

Tessel was all based on JavaScript. We were both new to this language and hence faced certain challenges while comprehending the code which was already there in Tessel. But, our mentor Kelsey, along with one of our coaches, Divam, helped us figure out the keywords used in the code snippets. With this help, we were able to make some tutorials for a few functionalities in Tessel in JavaScript.

A shoutout to the amazing Tessel Community!!

Our blog couldn't be complete were we not to thank the awesome Tessel Community that made our descent into open source a fun and a smooth ride. Every call with Kelsey would begin with her asking us whether we had been achieving whatever we planned for. She even asked if the tasks for the week were a lot or too little. But she always ensured that we had the right amount of work on our plate for that week.

Our weekly calls with Kelsey, our mentor, were the times where we learned the most. The timely response of the community members on any of our doubts were commendable. Any PR review would come in a day or a two, and the reviews gave us a different perspective on the issues. Nick and Kelsey, both Tessel Steering Committee members would leave comments asking questions about our code, which would force us to research more on the issue.

On our third meeting with Kelsey, she had said that "It is better to over-communicate rather than under-communicate" and thus, we would (shamelessly 🙈) ping them on Slack or on the issues whenever we were stuck, and a descriptive solution to our questions would follow. Many a time, Kelsey would explain to us our doubts on our call. Despite whatever mistakes we would make, the committee members were always positive and ensured that we were able to rectify our errors and learn from them. Many times, they've tagged us in issues that they thought we should be aware of and sent us links and resources to escalate our learning.

Tessel has provided us amazing an mentorship experience, one that is really hard to find. We are so glad that we began our journey into open source with such a welcoming community, so much so that we are more than willing to work for Tessel even after RGSoC is over. Tessel, We love you!

Extras

In these three months, we not only focused on core development work but we also presented a few lightning talks. We gave two of them - one for Women Who Code, Delhi and another for LinuxChix India. The LinuxChix India Meetup focused more on open source contributions, RGSoC and Tessel. Our supervisor Vaishali had introduced us to the community and put us in touch with the organizer of the meetup. We spoke about RGSoC - How to apply, what we do, our work, our social media, our blog posts, everything. After that, we went on to demonstrate our project - Tessel. There were several open source enthusiasts who had loads of questions about Tessel, and we were delighted to answer them. One person even wanted to use Tessel in his project that he was thinking of starting!

It was a great experience for both of us because we were able to pass on our knowledge to an enthusiastic crowd, get rid of our fear of speaking in front of unknown people, and gaining in depth knowledge of the topics involved. We had to explore every nook and corner of the topics in order to make our sessions productive.

What's next?

RGSoC provided us with a whole lot of things that we didn't even imagine gaining in this interval of three months. As it was a wonderful journey for both of us, we have thought of recommending this program to more and more people by conducting a few related meetups at our University under our Rails Girls Summer of Code, Delhi Chapter. Apart from this, we had discussed way back with our mentor during the application process that we would love to contribute to Tessel even after RGSoC ends. The months might be over, but the memories are here to stay!

Who would know that two confused, scared and shy humans who had absolutely no idea how they would survive the tech world could successfully complete RGSoC, loaded with experience and confidence?

Check out Rails Girls Summer of Code (it's not just for Rails), and get involved as a mentor or a mentee for 2018!

[highwaytorails]

Day 61 - 26.09.2013 - Cron Job, Rake Task, being sick

It's getting cold in Berlin! We long for the days when we were stuck to our office chairs and all the fans were running on the highest possible level.

But let's not complain about the weather. Our App is up and running (on staging, though) and even Susanne's mom has access to it now. 

The cron job we had kind of already finished yesterday, with the help of the whenever gem. Turns out, heroku might have something against whenever. We'll fix that tomorrow.

So this morning we started off with implementing our rake task, which in turn will be called by that cron job. Our rake task lives in lib/tasks/matcher.rake and looks like this:

It is calling our run method from our matcher class (the heart of our app). If we now type "heroku run rake matcher" alarm mails get sent out! Let us know if you want to get one too!

That's it for today. Two moar days and we'll be like this: 

Sniff.