Fedora reports | FOSSASIA

I’ve already written a general blog post about the entire Cambodia trip last time; I’ll use this one to report Fedora-specific information 🙂

Starting off with the first day, here’s the agenda:

First day – 28th February 2014

> Fedora Next: An Overview: by Truong Anh Tuan
> The Ultimative Fedora A-Z Talk: by Gnokii
> Introduction to FOSS techniques (aimed at students): by Sarup Banskota, 1 hour workshop
> Testing Fedora cloud images in Eucalyptus private cloud: by Kushal Das,
> 7 Ways To Contribute To Fedora Without Programming Skills: by Gnokii
> Fedora Ambassadors Program: by Truong Anh Tuan

Before the Fedora track started, there were few keynotes including one from Cat Allman and an interesting one from the Embassy of Sweden in Cambodia. Most speakers took more than the allocated time and that led to our Fedora track being shifted by a bit. As part of these sessions, Tuan introduced the Fedora community to the young crowd. Following this, we broke for lunch.

As per schedule for the Fedora track, Tuan did his first talk on Fedora.next, pretty interesting one, followed by Gnokii’s incredible Fedora A-Z talk.

Next was my workshop on Getting started with FOSS techniques. Kushal did one after me, on setting up Fedora cloud images on Eucalyptus. Gnokii’s last talk on ways to contribute to Fedora when you’re not a programmer was useful for me to learn more areas for me to contribute.

Second day – 1st March 2014

> Document your code: by Kushal Das,
> Building a Fedora Clustering/Load Balancing System using Linux Virtual Server: by Nguyen Nang Thang, Workshop (1 hour)
> OpenShift Origin – Open Source Platform-as-a-Service: by Uditha Bandara Wijerathna
> Fedora Design Suite: by Gnokii
> GlitterGallery for Fedora design work: by Sarup Banskota
> Logical Volume Managment(LVM) with Fedora: by Uditha Bandara Wijerathna, Workshop (1 hour)
> Building a Fedora Clustering/High-Availability System using Pacemaker & Corosync: by Nguyen Nang Thang, Workshop (1 hour)

The day started with Gnokii’s incredible workshop on Inkscape. Going by the feedback, I’m sure it was one of the most loved sessions at the entire event. Kushal went up next, with his Document your code workshop. It left me with few interesting things to Google at the end of the session.

Uditha was up next with his talk on OpenShift Origin. He also did one later on LVM with Fedora and going by the questions he was getting, the audience seems to have benefited from them. In between these talks, I did one introducing GlitterGallery after Gnokii’s talk on Fedora design suite. There wasn’t much audience for this talk of mine, but I did try my best to explain the idea to whoever was present.

Third day – 2nd March 2014

The last day was reserved for a hackfest at the Open Institute in Phnom Penh. We had a room to ourselves. We had few newcomers to Fedora and everyone worked on setting up wikipages, creating FAS accounts and signing GPG keys. Fedora also got their first two ambassadors from Cambodia! 😀

Once again, I thank Fedora for facilitating this for me by supporting my stay and travel funds!

Learning to say chomreabsuor!

Recently, I traveled to FOSSASIA 2014 at Phnom Penh, where I was invited to speak about my adventures with developing free and open source software. I must add that this was my first trip outside the country. Thanks to the pleasant hospitality by the lovely folks at Cambodia, it was quite smooth! 😀

Young girls (mostly students) welcomed us speakers at the airport and handed us our package. I was impressed in the first ten minutes, when I learned they had very thoughtfully packed a SIM card for us in the package! I think every international attendee will tell you how useful they found it. I can’t resist mentioning they even arranged for us to get our SIM cards converted to micro-SIM cards if our phone required one.

Upon arrival at the hotel (which was amazing btw), I finally got to meet Gnokii (Sirko Kemter) from Fedora design team – I have known him for a year, but we never got a chance to meet before. Below is a picture of the stylish German in an Assamese Gamusa I had brought for him:

I intentionally arrived a day before FOSSASIA, hoping to catch a bit of Phnom Penh before the busy conference days start. I spent the afternoon with the Fedora team – we had lunch at River crown by the Mekong river (where I tried the Amok) and we followed up with frozen yoghurt from an ice cream parlor.

Unfortunately, I was extremely tired and ended up sleeping through the evening beer party. Later in the night, I joined the other guests for dinner at a nearby restaurant that served local food. I liked some of it, although being from India I found it to be less spicy. Vegetarian guests seemed to have a tough time, because the majority of the local food appears to be non-vegetarian.

The conference itself was great. The venue for FOSSASIA this year was Norton University, so the event saw quite a lot of student participation. There were several tracks, one dedicated for Fedora. I’ll write more about the Fedora track and lessons we learned in my next blog post.

I did two sessions at FOSSASIA this year. One was a mini-workshop on Getting started with FOSS techniques (primarily aimed at the student audience). Also, I did a talk on Using GlitterGallery for Fedora design work. Slides for both my sessions are linked at the end of this post!

Following up with the interest on day one, my friend Rahul and I went to Ganpat Global Educorp, Phnom Penh, to do a similar session on getting involved with open source communities. The audience was a mixed one, so we tried not to keep it centered around programming. From the response I had on my email, it seems like they really loved it!

Sadly for us, in the rush we missed out on the Mekong river boat dinner party they had organized for speakers. Rahul and I went to the riverside for dinner and tried some of the local stuff once again! This time I remembered to ask for extra spice and we ended up with an awesome 10$ dinner!

The second day of conference was pretty intensive. We had more talks in the Fedora track scheduled around a wide array of topics. In the evening we had an awesome socializing party at Park Cafe Calmette. There was quite some incredible variety of fish and other forms of seafood. We also had a mini-dance moment – I’m sure the Mozilla folks from India (and the rest of us) will never forget Biraj’s exciting dance 😉

Following this, some of us headed to the night market to pick up souveniers.

The ladies with us will vouch for my bargaining skills 😛 It was fun – in India, bargaining happens through arguments, whereas in Phnom Penh, people tend to be more polite. I picked up some of the local silk scarfs, bags, key rings, t shirts and stuff of that sort.

The final day at FOSSASIA was reserved for hackfests. As usual, we had one room for Fedora activity. It was fun welcoming new contributors, helping them set up their machines and signing GPG keys. We spent the afternoon at a nearby local restaurant. I did a quick trip to the Genocide Museum before my return to India the following day.

I’m thankful to Fedora for supporting my trip and to the organizers, especially Mario and Hong Phuc for the phenomenal arrangements! Now let’s see if we get a chance to host FOSSASIA here in India next year;-)

Slides:
[1]- Getting started with FOSS techniques: http://www.slideshare.net/sarupbanskota/sarup-fossasia-1
[2]- Using GlitterGallery for Fedora design work: http://www.slideshare.net/sarupbanskota/sarup-fossasia

Beach to interview room in 24 hours: the Goa story

The last 3 days or so were super energetic – along with a bunch of friends, day by day, I went from uniform to underpants to formals! 😀 Now that I’m back home from the Goa Project & have made some time after class, here’s 5 things I picked up this weekend:

5.  Travel alone, pack less, shoot less, remember more. I’ve been lucky to have had opportunities to travel quite a bit recently. This time I carried just a backpack that carried literally nothing – a pair of ultralight clothes, my notebook and toothbrush. I must say that was really worthwhile. It eased off so many problems – having to carry extra weight, worrying about the bag getting lost, putting everything in place once you have unpacked. There was space left for me to carry back a bit of clothing I decided to pick up in Goa too! To my surprise, Mahesh Murthy offered similar advice on his talk about Travel Hacks (which was awesome btw, only that it stole my audience as they ran his track parallel to mine :P). I managed to attend the last few minutes, I really loved the way he presented neat hacks, one per slide. One of his equations I’ll never forget – if you’re traveling for n days, carry n/2 tshirts, n/3 pants and n undies. 😀

4. Warm up before you do anything. Not warming up has screwed me up my entire life. The course of my BoF meet went slightly off-plan. Delayed timings, TV to project slides, slightly non-relevant audience. I think it would have been useful to have skimmed through the slides before presenting – it wasn’t too bad, but with the kind of involvement I have with the topic, I could have done much better. On the other hand, today I entered the interview room with an XL smile and things did turn out to be super good! So I’ll remember to warm up before I do stuff next time –  exams, presentations, anything.

  3. If you have something to talk about, you’ll be fine. For the last two years since I’ve known him, Anirudh has always cribbed about how he doesn’t find people with similar interests. At TGP, it seems like he did! Which is interesting; from a distance it looked like he was networking more than any of us! 🙂 When we got back here, I was a little worried about what I’d do in the mock interview scheduled for today. Although I have a pretty decent resume, I wouldn’t really enjoy being screwed over on politics or Java, two things I have very less clue about. It turned out to be a pretty kickass interview – just yesterday, my senior Shyam was explaining how interviews could be turned the way you want them to, and I had fun trying to do that today! It was just the matter of making the interviewer talk about things you know & care about. I found out that I stammer initially when I start explaining things to an experienced person – need to work on feeling more confident and secure when questioned about stuff I’m passionate about.

2. A little fun doesn’t hurt – bring company along. We went ahead and did some adventure sport in Goa (not for the first time, though). I doubt it would be as much fun for me if I didn’t have company. We also attended the El Banano, it was totally entertaining. I can’t help but wonder how much rehearsal time that guy must have put into it, all his life! As a follow up, apart from search for local food, next time I’m in a new place, I’m going to try and see what the local entertainment is like 😀

1. We’re very, very small people. If I had to pick up one thing from the entire 4 days that stood apart – I’d pick the play by the girls from Kamathipura. The performers were nine girls, ages 12-19 who have either grown up in red-light areas, have been forced to do sex work against their will, or are daughters of current sex workers. Among other questions they raised, some of them still play on my head in a loop – “Why do you treat us like dirt?” At the end of the play, I literally had goosebumps. It wasn’t out of sympathy, but out of guilt.

I think it was a great weekend – there are probably many smaller lessons that I didn’t cover here, but then I’m sure they’re in the heart. I’m looking forward to my next series of trips, the next one being 1.5 weeks from now! 🙂

So, what’s this “Tapping designer thought process” at TGP?

I was reading my software engineering book earlier this morning, where I found this quote by Marvin Minsky- “There is no computer that has common sense.”

As you read this, look around the page. You’re probably used to understanding what part of this text is the header, and what part is the main body. You probably don’t have to be told that the “follow” button on the Twitter widget needs to be clicked in order for it to do some action. We’re so used to this stuff these days, that it’s almost common sense. Designers.invent.commonsense.

I’m fascinated by these people. I’ve tried hard to be one too, although I’m mostly a fail at it. Aren’t you fascinated? Isn’t it amazing how this guy sits at a desk and makes a fancy swoosh, and now you’d pay a thousand bucks more just to flaunt it? At my BoF meet at the The Goa Project this year, we’ll discuss that. I’d like to learn more about how the best designers among you and your friends think. How you and your designer friends convert a boring product description into an admirable brand. We’ll try to learn from each other, how designers invent common sense.

What do I gain doing that? Well, I’m a twenty year old, I’m being taught to write seemingly boring computer programs in school. Owing to that hatred, I went ahead and learned to build web applications on my own and spent the last summer trying to help open source designers from the Fedora project collaborate on their design work. I co-authored GlitterGallery, something we’ve decided to describe as a GitHub for open source designers. In the process, I got a chance to interact with some designers, and from the looks of it, everyone would love something that would help understand how a designer creates awesome.

As per my googling-and-talking-around, there are no (both popular & effective) platforms for pixel ninjas to really showcase & explain the process of their design work. Such a platform could possibly transform the state of design education and hiring. From the interactions at TGP and mainly through the half an hour BoF, I’d love to return home with a better idea of how such a platform would be. 🙂

Who should attend? If you’re a designer who hates mailing lists to discuss design work. If you’re a unicorn herder who’s had trouble with client feedback. If you hire designers, or a designer waiting to be hired. Or, if just like me, God was unfair and didn’t bless you with any of those, but designers fascinate you and you’d like to learn from the other designers who’re at the event.

Looking forward to see you all in Goa! If you don’t want to miss updates, click that “follow” button on the right – I wasn’t joking, it actually works 😉

Here’s the thing on the funnel: http://funnel.thegoaproject.com/2014/297-tapping-designer-thought-process. If you’re up for a quick survey to help me with the talk, here’s a list of questions if you could please answer:

Email(required)

How are you associated with design?(required)

How do you typically work? Alone? In a team? How do you collaborate?

What kind of design work do you do? What tools do you use?

Any suggestions you have about this blogpost? How would you vizualize the utimate tool for designers to use to collaborate with the rest of the world?

Submit

Δ

I’m breaking up with that dawg

(This story may bear resemblance to real life incidents. Inspired by discussions with college seniors over a Bangalore weekend.)

 

Like most people, I have a procrastinator in me. Let’s call him Dawg.

 

For most part of my childhood, Dawg and I never really got to interact much. Till about age fifteen, Mom and Dad used to control most of how I performed in school, the way I dressed, or how I behaved with the neighborhood aunty. I left home when I was sixteen; Dawg and I have been best friends since. (Remember that evil friend who suggests we discuss girls three hours before an important exam? Dawg is that guy.)

 

At sixteen, I was in love with Dawg. While kids in China were hacking movie databases at night, Dawg would force me to lie down in the dorm room and think of hot girls who’d wear short white pants, lie down in the grass, smelling of Garnier shampoo. The next day I would head to the internet cafe and read articles about how doing that is crucial to one’s personal development.

 

At seventeen, I was beginning to doubt Dawg’s intentions. I had wanted to be one of those Chinese-hackers-at-sixteen too, but Dawg insisted that ‘experiencing the crazy things in life’ was more important. Again, while kids in India had now started rolling out their own companies, Dawg explained how it’s important to enjoy life and ‘do crazy shit’. “If you haven’t say, gotten drunk and landed into roadside trouble”, he continued, “you’re a boring guy”.

 

Sometimes I would just get mad at him. He was playing with my life, how could he? I had things to do – get a job, run a company, go places with good looking women, buy expensive cars and property and …

 

Living inside me, Dawg knew all of this. Whenever he thought that maybe I’m beginning to feel a little insecure about what I’ll end up doing in life, Dawg had a quick fix – a trip to the stationery store. He would make me pick expensive sticky notes in 6 different colors (one for each priority level) and diaries with photos of romantic animals every one month (presentation is important). He made me research off-budget phones that featured on off-budget magazines across the road next to home. “It comes with a free productivity app that will change your life forever”, he would promise.

 

I’ve dealt with Dawg for five years now. Thanks to him, I’ve experienced all kinds of positive and negative situations, that have served as valuable lessons. The last couple of years have been especially fast-paced – I’ve learned to program small things that make life easy, to talk like one of those guys who sell their artwork at around 3m a piece, I’ve hung out with girls that smell of multi flavored shampoo.

 

Unfortunately for both of us, we’ve spent twenty years knowing each other, and I’m going to initiate a break up.

 

I’ve been looking at minimal, problem-solving design patterns on the web for a while now, and I feel it’s now time I applied it in other contexts. There’s so much of clutter I’d like to clear – books I buy but don’t end up reading, useless apps on the smartphone, the smartphone itself, fancy notebooks and pens amongst other things. Unread books make you look at them twice and make you pick them up and get high. Same with productivity apps or sticky notes or memos and the like. All of these are those silly Dawg memories, and my new year resolution is to de-clutter and get rid of them all.

 

I know it isn’t going to be easy to get over Dawg, and maybe I’ll just be 75% successful, but that’s still a start. If I can focus on building cool things and blur the rest of the clutter, things will be way more peaceful.

 

I’ll miss you dawg, you were such a cute thing.

2013 Summer Logs

For as far as I can remember, the idea of summer vacations used to be awesome – involving long plans about stuff to get done, places to go, things to learn, and assignments to dig. But when they finally arrived, at least for me, they started with long hours of sleep, endless procrastination, and lots of regret. I always used to wonder what it would be like to spend a summer ticking off all of those things laid out in checklists I made during all major exams before the summers started.

This summer of 2013, I found out. 😀

Fedora

I was a big fan of the Digit magazine while at school. They used to ship GNU/Linux distributions with most issues, and I used to enjoy exploring them. Although I was no programmer/developer then, it was still a break from Windows XP (don’t look at me like that!). I still have a stock of all of those old LiveCDs at home!

The World Wide Web, Mozilla and GitHub

Let’s face it – my first major fascination towards WWW began with internet porn. 😛 That died soon enough, and I was quick at realizing that the power of being able to connect all the world’s people at almost no cost could be explosive.

Google and Facebook caught on, and in a few years I was writing computer programs that did meaningless things (I did that as schoolwork, and in my 20 years of life, no one from the Airways has approached me with offers regarding entire Airport Management Systems written in an hour).

I was learning to build websites as a hobby, people seem to want them all the time, and they’re particularly generous if you’re a decent designer. I learned HTML and CSS. I learned WordPress. I learned why people disliked Internet Explorer (and also spent quality time in the bath thinking of more trolls). I learned to love Mozilla.

A college senior got me a small assignment to do for one of Mozilla’s projects, and I was asked to “push my code to GitHub”.

Eventually I fell in love with GitHub. It taught me the fact that stuff on the web can be cool, free-as-in-beer, free-as-in-ads, generous with its code and still mint money (GitHub has open sourced its heart, the grit ruby library).

Yeswanth

Sometime in March 2013, when I was at Bangalore to attend Startup Festival, my (awesome) college senior Yeswanth brought up the topic of GSoC. This wasn’t the first time someone told me about it; I had attended a presentation on GSoC a year earlier at a FOSS meet Yeswanth and a few other seniors had organized.

Now obviously, the only things that attracted me were – “Google”, “5000$”.

The rest of this blog post will cover my GsoC journey, and for those you hoping to apply next year, I’ve included some tips in bold occasionally 😉
Fedora Returns

Kernel development never really appealed to me back then, because I hated anything that was not web development. I would only scrape Melange for “html” or “css” related projects. I would only look at the ideas page of organizations like Mozilla, WordPress and Drupal, whose interests were primarily on the web front. If you’re new, scrape everything. You never know if Mozilla wants a custom kernel for a special project. You never know if CERN software is looking to manage its finances through a web application.

I was particularly interested in a couple of projects by Mozilla, one of which I had a bit of experience with. However, it wasn’t the sort of thing I wanted to spend my summer doing. Once again, Yeswanth to the rescue. If you don’t find a project motivating, don’t do it. I’m a bit of a designer, and a GitHub fan. A GitHub for designers sounded perfect – I had wanted to make the jump to building web applications for a long time. I had been discussing with Emily (my mentor) over email about it already, and thanks to Yeswanth, I decided I was going to nail it.

I discussed more with Emily, researched my brain out, did a few rounds of proposals,and we finally had something approachable.

On the 27^th of May, I discovered I was selected. Now I don’t want to drill into the entire sequence of events, but here’s a few key things I learned and you should remember –

1. Mentors are busy people. Email them and wait, they’ll reply soon enough.
2. Yeswanth has spoken about it already – competition doesn’t matter. It’s how well you collaborate. I had several competitors too, way more experienced than I.
3. Be nice. Help out people in the forums, ask when in doubt, and do your homework. Google before you ask something, learn to rest on the shoulders of giants 😉

An incredible summer

Needless to say, it feels good to see your name associated with Fedora (if only someone told me this was going to happen in the Digit magazine days). 😛 I’m good with building web applications now – although I’m nowhere close to expert level yet.

In the meanwhile, GlitterGallery’s growing! We’re adding more features and enhancing it’s UI in our free time. I’ve gotten rich enough to cover my school fees. That’s a lot of things for one summer! I only run Fedora on my computer now, and I’m also making my way to contribute to its core!

The coolest part? I was able to strike out everything in the summer TODO list I made during the end semester exams, and it feels really, really satisfying! 😉

GSoC Wrapup – Introducing GlitterGallery!

The summer is coming to a close in a couple of days, so I’ve decided to wrap things up with an introduction to GlitterGallery!

We’re making the designer next door happier. GlitterGallery hopes to do to open source designers, what GitHub did to the developer community. Forget losing design work, or having to scrape through endless emails to understand feedback. If you’re a designer, GlitterGallery is where you’ll be spending all your time in the near future. Welcome to the new office!

The effort was started by a couple of designers from the Fedora design team (one of them being my mentor, Emily Dirsh). Before I joined this summer, you could create projects and add files to them. These files would be checked into git repositories in the background. There were some limitations with the way the project was developed until then, that wouldn’t let us add many features to it. I spent most of my summer trying fixing that, and I’ve been adding more features ever since!

Anyway, coming to the features 😛 . We’re polishing the interface right now, so you’ll have to wait a while till these hacky screenshots get prettier 😉

So to start with, you can create SVG images on the fly. Just start a new project, and let our in-house SVG-editor help you create awesomeness. Already have them on your local? We’ve got you covered – just upload! In the backend, we work in a very similar fashion to GitHub (in fact, we use the same git library). So every time you create/upload a new image, you’ll see a new addition to your project’s commit history (yes you can see them all!).

We’re also letting you edit the SVG images you create within the app itself (as you might have guessed by now, we don’t want you to leave once you’re logged in 😉 ). Soon enough, we’ll provide support for you to track down a particular commit and start working off the changes you had then.

You no longer have to upload images on imgur and link up over mailing lists (phew 😛 ). Just make sure people have the right link, and they can comment on your work! You don’t have to limit feedback to individual images – comments are also allowed on entire projects, commits and glitterposts.

Glitterposts? Well, we thought it would be quite silly if you had to go elsewhere to write blog entries about how well-received your designs were. As a result, we’re letting you write your own blog posts on GlitterGallery! 😉 Although I’ll have to admit that isn’t as polished as it can get. It’s a very simple blogging system right now, but we’re sure that isn’t going to be the case for too long 🙂

There’s lots of work in progress at the moment. Just to give you an idea about what to expect by the end of this year, we’re currently investing time on perfecting how the fork/pull request mechanism works. You’ll be able to fork and contribute to any project, just like you can on GitHub. Once that’s done, we’ll shift all our energies to make the whole thing more social – we’ll let you follow your favorite pixel hackers, add badges, get inspired and more!

Another important feature that’s work in progress is the integration with SparkleShare (an open source alternative to dropbox). With that set right, you don’t have to bother syncing your desktop repo with the one on GlitterGallery. Make changes to the local, and it’s auto synced with us. Make changes on GlitterGallery, and it’s auto synced with your local 😉

You can find GlitterGallery on GitHub[1], and you’ll notice we’re open for contributions. We have a wiki[2] too – that’s where we’re adding artwork and documentation for now.

If you’d like to contribute in any way (doesn’t matter if you think you don’t know much – we’re eager to help you learn), just shout out to @emichan and @SarupBanskota on Twitter. You can use the same to ask questions or to just say hello. There’s more ways you can communicate, all of that is outlined on the wiki[3]. A good place to report problems is the issues page[4] – if something fails, or if you have a new feature request, that’s where you should list them out!

It’s interesting to note that when I started out, I had absolutely no idea what the heck this Rails phenomenon was all about. Now I do! – I’ve picked it up fairly quickly, and in about two months of time, Glittery can do a decent job helping designers. Of course, it isn’t fully featured in any way yet, but I’m sure that isn’t going to be too long. Well, we did hit a roadblock once, and that sort of slowed us down, but now that things are fixed, we’re moving really fast!

For at least one thousand students from around the world, this has been one heck of a summer. Google Summer of Code is going to wrap up in a couple of days and I’m sure all student participants would have put in a good deal of work into their respective projects. Personally, I had a great time – it’s an awesome feeling to get lots of code accepted into a futuristic project, make connections and grow rich all at the same time. I’d like to thank everyone who helped me out – Emily and the team at Fedora, Yeswanth and Anirudh, Sumana from Wikimedia, Aswin, family and friends who supported me in various ways throughout the summer. And oh, Google. Thanks a lot guys!

Alright, thanks again for reading, and cheers to the awesome summer! 🙂

You can try an instance of GlitterGallery at glittery-banas.rhcloud.com.

[1] – https://github.com/EmilyDirsh/GlitterGallery ;

[2] – https://github.com/sarupbanskota/GlitterGallery/wiki/ ;

[3] – https://github.com/sarupbanskota/GlitterGallery/wiki/Contributing ;

[4] – https://github.com/EmilyDirsh/GlitterGallery/issues

SFD at college!

This time around, some of us free software enthusiasts at college decided to celebrate Software Freedom Day. It was a beautiful event, and the student crowd seems to have enjoyed it! Post event, I’m getting lots of requests for contributing to GlitterGallery as well, which makes me really happy!

A junior of mine, Abhishek Ahuja, wrote a great report about the event, so I thought I would include that here 🙂 We’re still processing the pics, so I’ll add them here soon! Following is Abhishek’s report:

As customarily celebrated all over the world on the third Saturday of September, this year Software Freedom Day was celebrated for the first time in Amrita School of Engineering as well. The main focus of the event was to spread awareness about the definitions and privileges of free software. The academic society, here and now, is largely unaware of the existence, not to go so far as the advantages of free software. Students, as well as trainers can be made to spend their time and efforts more productively if made to collaborate efficiently. Proprietary software like Windows, though common and familiar to most, is inconvenient to many, but still, people do not say against for the lack of knowledge of alternative systems. People do not mind spending two minutes for a scan every time they use a flash drive, to be sure it is safe for their computer. This act would be unnecessary, if the said person were using, say, a linux-based operating system, which does not react in any way to malware. It is not something we would think much about, but then again it’s one of the small things that happen to affect us in a big way. A programmer should use a computer as a tool, but if he is so scared that his tool may fail to perform every now and then, and spends his energy trying to make an exhaustive list of all the things that can go wrong with it, then the person concerned is more of a servant to the machine, than the other way round, as is meant to be. The above example is only one such instance of why proprietary software is inefficient. Many more such everyday actions performed on computers can be cited, with pretty much the same result. The point is not to eliminate Windows entirely, it is to put to use only where its use cannot be avoided. This is an aspect of software most people will not fully understand until they are exposed to both platforms of computing. Thus this workshop made students realise that they had an option, they had the freedom to choose what platform they wish to work on, making an informed choice in the process.

The event kickstarted with an introduction to the idea of open source by Abhishek. He explained why it’s logical to invest in free software. He spoke about some of the popular distributions available, along with open source software that could be used on platforms such as Windows, for those not willing to migrate to Linux. This was followed by a talk on what distro suits best for people based on their needs, by Sharad.

The workshop went on to discuss other success stories of the open source model, like the Linux kernel, Wikipedia and git and also the process of co-operative development was brought to light since one of the speakers, Sarup, is an active member of the developing society. Sarup also discussed open source from a student contributor perspective, emphasizing on the fact that one doesn’t need to be a master of any specific language or technology to start – they just need to love their favorite open source projects well enough. He introduced resources such as OpenHatch, where newcomers can look for good first bugs, along with a quick primer on version control using git and collaboration on GitHub. He spoke about various programs students can involve in, such as the Google Summer of Code and Season of KDE. Finally, he encouraged girl students to contribute to open source, introducing some eminent women in open source and programs such as the Gnome OPW.The whole event wasn’t just limited to the power of software, there was a session on Open Hardware too. Aravind introuduced the enthusiastic student crowd to Arduino. He encouraged the attendees to come up with crazy ideas for hobby hardware projects. Students who came up with interesting ideas were thrown some goodies too!

A major attraction to the event was the installfest. The attendees were asked to bring along their computers and a flash drive, as part of the event. Distributions of open source software were given to the attendees and they were assisted in installing Linux-based operating systems on their computers. This was the action part of the workshop which complimented the remaining speaking part. The attendees were excited and pleased to walk out with their newly-found (realized) freedom and the will to experiment and curiosity to learn more.

How Glittery will evolve its comments mechanism!

Just in case you missed the previous post about the architectural changes we’ll be making to GlitterGallery, you can find that here.

Since Glimages will now be shown through the blob object’s data, there’s actually an advantage  – we can now support comments for every point in history for a particular Glimage. The URL for a particular commit will contain the sha for the commit. (An SHA is unique to a commit).

So, all we have to do now, is grab that SHA, and assign that to a comment. Just like we relied on the glimage_id column earlier, we’ll now rely on the commit’s SHA for the same!

Of course, we’ll want to assign these comments to Glitterposts as well, so’ll actually be dealing with two columns. type and type_id. It probably makes sense to prettify things a bit, so we’ll organize our tables in this fashion (comment_holder connects those two tables):

This looks error free to me so far, although if you have any feedback, you must let me know! 🙂

Glittery’s changes in the file storage schemes

It’s been quite a few busy days for me. I’m here at PyCon for the weekend, and there seems to be a cool arrangement (beds with pillows, wifi etc) for people to work on their personal projects, and also for those up for some weekend hacking!

Anyway, I spent a good chunk of the day planning possible changes to Glittery’s file storage concept. The previous model relied on a Glimage model that belongs to Projects, but that seemed to turn out as a barrier when I tried creating Glimages through SVG-edit, and also when I spent time implementing the fork project function (Similar to GitHub’s).

I guess we’ll now drop the Glimage model. We can fetch the Glimages through image names commit SHAs that we pass in the url. Although Glimages can no longer be individually private; we’ll go ahead and allow projects to be private (not accessible to anyone other than the author).

The only problem I can directly see coming up is the comments attached to the glimages. I have a workaround for this, although I’m thinking of a better one. Comments are served as polycomments, so we’ll just play around with the type and type_id attributes.

So now the flow happens this way –

1. User signs in and creates a new project (possibly with a glimage upload)
2. We assign a non-bare repo for the project, and clone a bare repo from it.
3. Every time a new file is added or updated, we commit to the non-bare repo and immediately push to the bare repo.
4. When viewing glimages, history and current status can be obtained via the grit API.
5. Pushes made from forked projects will go to the parent repo’s bare-repo and changes commited to the non-bare ones.

This is the vague idea as of yet. Emily’s been saying something about post-receive hooks that I haven’t understood anything about. Will probably check that out tonight and I hope this will be a refined blogpost by tomorrow (with handmade graphics 😉 )

Update – I’ve added a post about how the comments will now be handled here.

Glittering updates!

Apologies for the hiatus in posting – let’s say I just got drowned in schoolwork. This semester looks amazing (wrt the courses), but TBH it’s quite easy to get bored in class. I’m happy Vidhya Ma’am is our Algorithms trainer, she’s just really good. Finally some challenging problems to look forward to in class 😛

GSoC has been going great too, and I passed my mid-evaluations successfully (yay!) 😀 My mentor and I had a nice meeting last Friday over Skype and I’m glad she seems satisfied with my performance. 🙂

Here’s the Glittery TODO status:

1. Style Glitterposts
2. File level history
3. Style commit log pages
4. Plan the fork process.
5. Style comments

Here’s a quick summary of what happened over the last couple of weeks:

• There was an extremely weird scenario with the glimage’s file level history. While everything seemed right code-wise, my browser would render SVGs with clearly different source as the same! Turns out you’re supposed to assign unique IDs to SVGs if you’re displaying more than one at a time on the same page. While I broke my head for quite some time on this, Emily was quick in pointing this out! 😀
• I’ve been pondering over the right way to deal with SVG files created on the the fly. It didn’t take me too long to get SVG-edit to work on the new_glimage page, but there are certainly inconsistencies with how I should store these SVGs created on the fly, as opposed to those manually uploaded by the user. I’m going to give it a few more days of researching, and if nothing else works, we’ll have to do a bit of an ugly user-experience hack – allow users to create the SVGs online and then download them. Then ask them to upload them back again.
• I’m currently reading up about the fork() process from the grit library, have some confusions. I’m able to get the user to fork a project, but the created project doesn’t have the source files.

As for schoolwork, I seem to really enjoy Operating Systems Principles, not sure if that’s because of a certain emotional connect with the Fedora project. 😉 Alright, I’ll try to be more regular with the posts next time.

Cheers!

GSoC mid-iteration 2 updates!

I had to skip one Sunday blog of GSoC updates because my mentor and I couldn’t really catch up on time and I was a little confused about what to do next.

Anyway, the good news is that I was delaying by almost 10 days at one point, but as of today, I think we’re ahead of the schedule 🙂

Here’s the TODO status for the past two weeks:

1. Fix polymorphic comments – they are failing even though the models seem to be fine.
2. Investigate why migrations are failing on production and try fixing that.
3. Style Glitterposts.
4. Allow users to follow each other.
5. Fix the issues in the pull request caused due to rebase.
6. Given a project, display its commit history.
7. Facilitate going back in history and being able to view status at that point in time.

Polymorphic comments were failing because earlier, I had failed to determine what model any comment belongs to. Turns out that had led to other complications, which I was successfully able to resolve last week.

I just have to get over the laziness and write the CSS for the Glitterposts and the rest of the application. Most of the upcoming week’s activity is over, so I think this is just the right time to do so. I’m almost going to dedicate all of this Sunday coming up with a new design scheme. As for the user follower model, I have decided to fix that feature altogether for now, and will work on that when we’re making a user page. Without that, such a feature wouldn’t make a lot of sense.

As for the weird pull request, I could figure out what was wrong, although I couldn’t determine how to fix it. I spent an entire night at home, and both my mentor and I decided the best thing to do was to start the repo afresh. I’m hoping the stuff in the new pull request 23 please Emily and she pulls it in 😉

The front end for the underlying git backend is good for what features we have now. People can view the history, and go back in time and view how glimages and other files were at that point in time.

As for the coming week and later, here’s what I have in mind:

1. Write the tests if possible. I know I’m doing very bad BDD, but the learning curve is too high for the time I have in hand. I may need one of those productivity management books anytime now 😉
2. Prettify, prettify, prettify.
3. Study up on the school stuff. Might as well do a few resourceful posts 🙂

What the hell is an MVC?

Web applications are already making it possible for you to ruin your future, tell everyone, then vent your frustration on Google, and brag about it.

It’s becoming easier than ever to build web applications these days (ask Mum). There are as many web frameworks available for use, as there are applications, making it difficult to learn any one of those in peace. Even if you don’t program, you’ve almost certainly heard about “Ruby on Rails” or “the Zend framework”. Those are only two of the many that utilize the MVC.

The what?

MVC. Short for Model-View-Controller. Let me explain in detail. Most applications have a GUI component that users can interact with. There are buttons to click and forms to fill.

What happens in the background when you click those buttons? Where does the stuff you fill go?

Models are data structures. All your kewl names (Suppandi, GaryTHEFish, missTika) – they’re attributes of Model objects. Model objects are instances of Models. An attribute is what helps discern one model object from another. So while it may not matter much how cool your name is, it’s existence is important. Depending on the application, you need to have a nick. An email address. A profile picture.

Most of these attributes by themselves are just raw datum. When you put that together you’ve made something useful – a user. An instance of the User Model! If you know what OOP is, this should be your gotcha moment 🙂

Typically, modern web applications rely on many models. All the world’s status updates are objects of probably the Status model. All statues possess exactly the same attributes – the text with the status itself, the number of likes on it, the time it was created. In the database, they are probably identified with let’s say, a unique serial number. So you can look up Status #56 and you can check if the author liked it himself. Models map to databases.

Moving on to views. When you want to display the statuses neatly on a web page, you’ll probably want to add a blue border around it. Maybe make a few red buttons blink on one side too, so it attracts people to click on it, right? Views help you with that. What you supply to the user’s browser is a view. Views contain the forms, the buttons, the text – if you’re just a normal user browsing the web, you’re pretty much interacting with views.

So how are models and views related? For most applications, views are what allow users to interact with model objects. So views contain stuff like the </html> for the forms, which renders on the user’s browser, and which the user can use to enter fancy nicknames. Make sense? Great. Mum is proud of you.

Now look at this form.

User enters the nick on the form and clicks the submit button. The goal is to associate it with an object of a User model. But… who facilitates this transaction? The stuff users enter are on the form right? Now how the heck does it land inside a database? How does it associate with a model?

The Controller! Controllers receive all the content of the form, create/update Model objects with those attributes, and then a database entry happens. How Sparkly!™

But that’s not all the controller does! Let’s suppose you were lying about your email and it was already owned by someone else. Mum wouldn’t be proud of that, right?

The controller will help find out if the database entry was successfully handled. If the User model allows multiple users to possess the same email, then cool. If it doesn’t, the controller will decide what to do next (hint, probably ask you to re-enter a different one?)

An important thing to add: MVCs are almost invariably accompanied by Routes. I honestly don’t know why it isn’t called an MVRC or something (it probably doesn’t make a great acronym), but it’s important for anyone learning about MVC to know what Routes are. Routes help you create the URIs that we see on browser address bars. Routes will decide what method of let’s say, the registrations_controller is to be associated with the signup page. You’ll understand better once you’ve worked on an MVRC system such as Ruby on Rails.

Alright, I guess now we’re equipped enough for some philosophy. FAQs:

1. Why MVC?
   • It’s a useful paradigm that helps you amicably separate your presentation from your application logic & the data structures you’re dealing with. Frameworks very powerfully let you exploit that, hence making possible for you to come up with powerful applications in very less time.
     Since the development is now divided, it’s also easier to let experts deal with different areas in which the application needs attention.
   • Easier to spot where you are going wrong.
2. Where to go from here?
   • Simple, make an application. Try any MVC framework for yourself. It’s sometimes hard to absolutely stick to MVC guidelines, but if your thing works, I don’t see why it’s a concern.

Hope this was a quick guide for anyone who wanted to know What the hell an MVC is. 🙂 Cheers, and remember to share if it helped you! Feedback welcome!

First iteration outcomes!

I’m a little late this week, owing to Calcutta-heat-induced-laziness. Just a week before college starts and then I’ll finally enjoy some great weather! 😀 Anyway, quite some stuff is happening on GlitterGallery!

TODO Status:

1. OpenID integration
2. Fetch email and nick through SReg
3. Glitterposts for users
4. Improved comments based on User details
5. Make comments polymorphic
   
6. Followers for people, projects
7. User page (just a stub for now)

Additional fixes I need to make:

1. WordPress authentication doesn’t work as expected for some reason, although FAS works perfectly.
2. Glitterposts need to be styled, etc
3. Polymorphic comments are good model wise, but they’re failing for some reason
4. Migrations are breaking on OpenShift. Have to investigate.

Now coming to the details, the thing I found most difficult was integrating OpenID. The documentation is extremely old, and almost every new gem seems to fail due to some routing issues. Finally I managed to capture the essence of the old docs, and with some luck over lots of coke, it works now. I’ve covered the full process in a dedicated blog post. I managed to fetch user details through OpenID providers (personally, I use FAS) through SReg, although  auth through WordPress seems to fail 😦 I’ll hopefully invent a workaround soon.

Glitterposts have turned out great, although they could benefit a lot from some crazy styling. That’s for one lazy afternoon, although I think I already know where to drive inspiration from 😉 I don’t know if I’ll end up replacing the whole system with one that provides a bit of CMS facility. We probably don’t want as much complexity right now, although a few extra features would be welcome!

What I really want to fix right away is the comments – the idea being that if I can make them work for one model (say glimages), they’ll work for anything else. I will take a look at the polymorphism first thing tomorrow.

Emily and I will hangout soon, and once we do, we will have a better idea of what needs to be worked on next! 🙂

Cheers.

Setting up OpenID on Rails

Until last week, GlitterGallery used devise under the hood for it’s traditional authentication system. This week, I replaced that with one based on OpenID. This post covers the strategy I followed. If you’re looking forward to setting up an only-OpenID based authentication solution on your Rails application, I recommend reading this because from my experience, the available documentation is quite old and limited.

remove existing authentication system completely

If your app has no authentication at the moment, you may skip this section. If your application uses devise for authentication, check out this thread to remove devise. I don’t have experience with other auth systems, but my guess would be that removing authlogic and others should be similar.

add the new dependencies

We will work with JanRain’s library for OpenID on ruby applications, and a wrapper to make the process simpler. Add the following to your Gemfile:

gem 'ruby-openid'
gem 'open_id_authentication'

Now run bundle from inside your app directory:

$ bundle install 

add a sessions controller

The idea is that every time a user logs in to our application, we start a new session. To cover that logic, here’s what we’ll begin with:

class SessionsController < ApplicationController
  def new
    # spits out a login form to start session
  end

  def create
    # contains the logic for handling the stuff
    # obtained from the login process
  end

  def destroy
    # contains the logic for destroying the user
    # session (logout)
  end
end

add a sessions resource to routes

We’ll now add a singleton resource to the application routes (config/routes.rb). Notice that we skip the edit functionality because we don’t need it:

resource :session, only: [:new, :create, :destroy]

add a view for the login form for new sessions

Note that I haven’t added any fancy formatting here. OpenID recommends additional formatting guidelines, so you might want to read through this.

<%= form_tag(session_url) do %>
  <%= text_field_tag "openid_identifier" %>
  <%= submit_tag 'Sign in' %>
<% end %>

create a user model

If you already have one, you’ll have to add an accessible attribute field for the identity url:

attr_accessible :identity_url

Also remember to ensure that you have performed a migration to add an identity_url column to the user’s table.

create the login logic

Alright, here comes the fun part. Here’s what I did to create the session once a user has entered his OpenID url on the login.

  
def create
  authenticate_with_open_id do |result, identity_url|
    if result.successful?
      # FIXME - needs normalizing before
      # checking for the identity_url
      unless user = User.find_by_identity_url(identity_url)
        user = User.create(identity_url: identity_url)
      end
      sign_in user
    else
      render 'new'
    end
  end
end

#FIXME – Before you save the identity_url into the User model, it’s good to normalize it, so all identity_url’s are consistent. For example, (http://sarupbanskota.id.fedoraproject.org) and (sarupbanskota.id.fedoraproject.org) shouldn’t be treated as two different urls. I’ll show how, soon.

add helper methods

Now we’ll have to write helper methods to facilitate the sign_in. How you do it depends on your plan, here’s how I did:

module SessionsHelper
  def sign_in(user)
    cookies.permanent[:remember_token] = user.remember_token
    self.current_user = user
    redirect_to dashboard_url
  end
 
  def current_user=(user)
    @current_user = user
  end

  def current_user
    @current_user ||= User.find_by_remember_token(cookies[:remember_token])
  end
  
  def signed_in?
    !current_user.nil?
  end
  
  def logout
    self.current_user= nil
    delete.cookies[:remember_token]
  end
end

create the signout logic

This is pretty straightforward. If you signed in following my process, then signing out is just a matter of clearing the permanent cookie.

def destroy
  logout
  redirect_to root_url
end

def logout
  self.current_user= nil
  cookies.delete(:remember_token)
end

include the helper in the application controller

Finally, don’t remember to include the helper method in the ApplicationController (app/controllers/application_controller.rb).

include SessionsHelper

With this, you pretty much have a neat OpenID system running. Of course, there’s a lot that can be added to this in the form of SReg extensions, but my goal was to keep the process simple.

Cheers! Remember to share feedback and as if you run into problems!

Summer of Code third week!

Three weeks down, and I’ve been writing a lot of tests for GlitterGallery lately. I’ll have to admit I wouldn’t have gotten up to speed so easily had my mentor not bought me a copy of Everyday Rails Testing with Rspec (Yay!) 🙂 I’ve been silently telling myself – if I ever happen to write a technical book, it would be written like that. It’s really concise, to-the-point, and does it’s job.

Being new to BDD, there’s a habit I would like to form now – draw on paper first, describe behaviors in pencil, then move to writing the tests, and only then, code. This is the approach that seems to work best for me, although I only realized it late this week.

TODO status for week3:

• Tests for User model
• Tests for blogging system
• Tests for comment system
• Tests for OpenID auth
• Analysis of following-users strategy
• Analysis of relationship between User, Project and Glimage
• Analysis of relationship between Comment and models that will use it.

Here’s the initial set of ideas I’ve come up with to refer to for the following week:

• Authentication
  • Emily and I have decided to stick to just OpenID for authentication now and replace the previous authentication strategy completely. So far my plan is to use omniauth on top of devise for authenticating, although that may change if I find easier documentation for playing around with another auth system. This also shows that documentation is really important when one is making software.
  • Using OpenID would mean we will now just ask for the OpenID uri. Essential things like email and username will be fetched from the User’s OpenID provider, and if there happens to be an attribute that we’re not permitted to use, we’ll direct the user to another page where she enters the remaining details. Fedora contributors can use their FAS account to login by entering username.id.fedoraproject.org as their uri, although if there are plans to make a custom Fedora-only version of Glittery, enabling users to sign in using just the username shouldn’t be difficult at all.
• User model
  • Largely, there won’t be a lot of changes right away until I dedicate some time to work on a User edit profile page. Until then, we’ll stick to attributes for username, email, openid_uri and a photo. I’m still not sure if we should continue using Gravatars, although I don’t see a reason why not.
• Comments
  • Lots of changes slated. First of all, the idea of allowing public users (read non-signed-in) to comment is a bad one, because anyone could pose as me, use my gravatar, and throw in a fancy comment. I’ll replace this completely to allow just signed-in users to comment, and we’ll make use of their user_id to fetch the rest of the user details. No more need to ask for author and email info any more.
  • Comments will now be polymorphic to be used with more models. It’s not the best idea to use it just with glimages, because projects, glitterposts, and newer models would need them to. I’ve already changed the db/schema, but need to make it work – it breaks right now.
• Glitterposts
  • This is a new feature. While its actual need is debatable, I think it’s convenient to let the users maintain a blogging system within the application – if most of their work is going to be built and discussed here, it makes sense to allow them to make announcements and discuss updates on a blog-like service. I believe GitHub allows that too.

Some of these changes will affect the other models as well, but I’ve decided not to include them here as there isn’t going to be much of a change in logic right now 🙂

In other news, I have developed a real bad wrist problem – it hurts at times making it really difficult to type 😦 . I just hope to get over it soon.

Cheers!

Second week’s design+rails experience

Time passes so quickly! I find it so difficult to realize that the GSoC coding period starts tomorrow! 😀

While the official coding hasn’t started yet, I must admit I did learn a few miscellaneous things over time. Two months ago, I remember being utterly impatient for a summer like this. I’m so glad it’s finally happening! I’ve summarized the previous week’s adventures in this post.

I started the week by prettifying GlitterGallery.Of all the techniques I went through to explore the Rails framework, I think that one was probably the most satisfying. I certainly feel more confident about why the popular Rails development processes are done the way they are (although honestly there’s still a good amount of Rails goodness that I find to be almost magical and have no idea about).

I’ve changed the color scheme to a more bright summer special one.

I was just thinking, probably the best thing that could happen to me is to have a designer for a mentor. So this summer is not just a code adventure, it is equally as much a design adventure too! We just discussed about designers last week on Monday, and I’m sure there’s a lot more to happen along the way.

Out of curiosity, I also read a little about scaling. I’ve covered that here. That post isn’t extensive yet, I will definitely have to do a lot of research before it becomes one. At least I have a starting point 😉 (As if things weren’t awesome enough, Emily is part of the OpenShift team, so I’m expecting to learn more about scaling from her as well.)

Coming back to Rails, I had a bad start again this week, but I finally ended up completing most of what I had planned! 😀 I had wanted to learn about secure and permanent authentication in depth, and I did. I have a pretty functional fun app here on my local server that I’ll probably deploy later this next week 😀 As a project intended to help me explore authentication, it surely did it’s job. 😛 Additionally, I also bought a Railscasts subscription (now that I’ll soon have some of Google’s money 😉 ). That was just yesterday, so I haven’t been able to do much with it already.

Here’s the TODO status for week 2

• Build two rails apps. Static pages, User model, normal authentication. Once with help, again once without.
• Allow signin/signout.
• Store many textboxs per user, kinda like a blog.
  
• Learn to authenticate via devise.
• Work on GG user model by studying GitHub and other services. –> following, projects, all that.

Besides quickly finishing up on these, I also have to think about the next week’s plans (I think that deserves another blog post). I’m completely excited – this will be my first experience with Behavior Driven Development and writing tests. It looks like the first coding week will be a little strenuous – there’s quite some tests to write, and quite some software to break. But more activity = more fun! 😉

Cheers to a crazy coding season!

How designers happen

When I designed banglewala in January this year, we just had a few product models to sell, and the goal then was to make a catchy, crazy and fun website. In terms of the visual appeal, I would like to think we were fairly successful – a lot of people told us they loved the website, and it did the job of making them curious about what we’re up to. As the team’s developer, I was never really happy with the navigation scheme we had. I’m not a seasoned enough designer to tell what exactly made me unhappy, but largely, I think it wasn’t intuitive.
As Aadharsh soon rightly pointed out, we weren’t selling bangles. We were selling the website.

This Monday morning, the day before Emily (my mentor at Fedora) left for the Red Hat Summit, I asked her a question, which led to what I’d think was a really productive discussion.

“I see that you are an interaction designer. What does an interaction designer do, exactly?”

While our discussion itself didn’t last very long, I spent a major part of the day reading up about all kinds of designers. I almost danced when I read how many designers seemed to share some of the same traits I generally have – nitpicking bad fonts at otherwise well done websites, being personally disturbed and unhappy about minor imperfections in the way program output shows up on the terminal, getting annoyed by unusual and distracting color schemes. But I’m sure I’ve never thought I misunderstand so many things about designers that we generally tend to easily assume.

As it turns out, design isn’t about making a lot of animation happen, or shading navigation panels in a certain way. Design is about making a product usable. Design happens within a lot of constraints, and good design is adaptable to them. A lot of the design exists to make the product feel “undesigned.”

I’ll take an example here. The quarter I live in Kolkata is terribly small, and err, dilapidated. The doors creak, the ceilings of the restrooms leak. If you open the fridge, you end up knocking the TV table on the side. A lot of my time is spent thinking about how such imperfections could have been avoided. Like honestly. What we could do to a table, so it wouldn’t shake, what we could do to retrieve items from the fridge without having to open the door (how about no door at all?)

When I was eight years old and living in Mumbai, I used to hate the living room. I remember the art school teacher complain to my Mom how I would be distracted with some irrelevant home layout sketches, while the rest of the art school kids would draw landscapes of rivers flowing through mountains. I just never happened to realize this far, that in all these ways, I was constantly designing! I was trying to solve problems!

I think designers happen when there are problems to solve. When I bought my first phone, I was confident I didn’t want a touch phone (“those rich kids who buy iPhones are idiots”). My priorities were always limited to making calls and sending messages, so I went ahead and bought the most basic kind. A year after free SMS packages started rolling in India, I realized that I couldn’t do without a qwerty phone! Ironically, after having used my (complimentary) iPod for a couple of months, I almost never use my qwerty phone anymore, except to make phone calls. My priorities still are the same – I only make phone calls or type notes. I still never seem to be attracted to games, or many fancy apps. But the whole touch experience is now intuitive to me – clicking buttons feels uncomfortable and artificial! That is what design can do to you. It evolves your intuitions.

People hardly evolve. As people use better technology, their intuitions evolve. People want to use things that doesn’t feel non-intuitive. Therefore, design evolves to accommodate intuition. That’s when designers happen.

I personally believe designers will steer the next generation of technology towards the future. If we need anything at this age, we need street-smart, entrepreneurial and talented designers to take on the world’s most important problems. And that isn’t just limited to fancy t-shirts, or better music players. Good designers will make life more comfortable, while keeping more urgent things like the environment in mind.

Color Scheme cheatsheet for GlitterGallery

#44342e#9f7d70#eee8e5

#94999c#bdc0c2#e6e7e8

#35b6c2#4fc4cf#caedf1

#fad804#fce451#fef6c5

#fe5906#fe8c52#febf9e

Rails adventure and the last week

Aaaand, it’s been a week of my Google Summer of Code! I’ll have to admit though – the last week wasn’t as productive as I would have liked it to. But that’s not to say I didn’t learn anything at all, or I didn’t do much. Quite honestly, I think I set myself a little too ambitious targets, without realizing it. I did complete a good part of them, but it’s disappointing when things don’t go 100% as planned. I’ll try my best to hit less ambitious plans from now on. 🙂

First lesson. Start the week with the thing that’s most important. The enthusiasm fades in towards the weekend and leads to a “let’s hurry up and skip this” situation. I started the week with a revision of Git. I would like to think it went really well, I understood a lot of things I didn’t get last time. I also made a Git cheat-sheet for the summer; I guess I’ll add more to it as I forget commands.

Second lesson. Before getting high about a fancy resource, skim through everything else that’s available, first. Rails for Zombies 2 was great, but I found Rails Tutorials by Michael Hardl friendlier towards newbies such as I. Unfortunately, I ended up spending the two entire nights on RfZ2 without really understanding anything perfectly. I think RfZ2 would be a fantastic experience once I’ve run through the entire tutorial by Michael first. Reading through the tutorial is probably a slower approach (being text), but is certainly easier to follow when starting out. I’m hoping to finish the entire book by Monday, and then catch up with some Zombieness.

Third lesson. See it in action first. I want to build this little app that scans your bookmarks and stores them online – a solution to a problem my friends and I face often. Following everything step by step in Michael’s lessons was not a bad idea – it gave me a good introduction to what testing really looks like (it was such a mystery until yesterday)! But it certainly wasn’t the best thing to do. It killed a lot of the spark of writing actual logical code, and I ended up spending a major amount of time writing tests for simple things. Next time, I’ll make it a point to make a working demo first, and then analyze – of course, this applies only when I’m learning.

Fourth lesson. We all need a short break sometimes. No breaks might sound like you’ll end up learning a lot more, but they end up distracting you. As a result, I’ve decided I have to redo my time adjustments and add more frequent breaks in between 😀

That’s it for this week. My current status with Rails is quite good (about to learn about user sessions and perfect my authentication skills), although I would have enjoyed it if I had completed the Rails tutorial by tonight. The weekend is hopefully going to be spent hacking on the GlitterGallery UI, so I guess it’ll be fun! 😀

And oh, I also came up with this fancy temporary tagline – All that glitters is GlitterGallery 😉

Cheers!

TODO status for Week1:

• Get up to speed on git. Blog.
• Get hands dirty with rails. Blog.
• Read up dgplug’s past class logs.
• Formulate an extensive deploy instructions list – needs confirmation from volunteer testers.