How to use your IRC Client


This is an (todo:illustrated) guide of how to use your IRC client, it will only touch those portions of the setup process which are relevant for the purpose. This guide will try to cover 3 IRC clients, namely:

  1. irssi (One of the oldest, most mature and widely used clients, cli-only, *nix-only) (Personal Fav!)
  2. XChat (Desktop GUI client, hassle free, free for Linux, paid for Windows)
  3. Chatzilla (Browser based addon, really easy to install, simple to use, free everywhere)

Short FAQ

So before you go further, this is a really short faq so that what follows has some semblance of order.

  1. Q: What is IRC? Answer: IRC stands for Internet relay chat, it basically refers to the entire system of global Servers, clients and people chatting online in global chat rooms. For the more curious, technical and boring among you here’s the relevant RFC.
  2. Q: What is this Freenode I keep hearing/reading about? Answer: Freenode is one of the most popular IRC servers online. Basically, you connect to an IRC server and join an IRC channel on that server and then talk to people there.
  3. Q: What are these weird channel things that look like #this-is-weird I keep hearing/seeing? Answer: The #things looking thing you see is called an IRC channel , once you connect to a server, you need to join a channel which in crude terms is the equivalent of a chat room.

I. Download your favourite IRC Client

IRSSI Install

  • For Fedora, CentOS users sudo yum install irssi
  • For Ubuntu, Debian users sudo apt-get install irssi or sudo aptitude install irssi
  • Other Linux distributions might want to use their respective package managers.

XChat Install

  • For Fedora, CentOS users sudo yum install xchat
  • For Ubuntu, Debian users sudo apt-get install xchat or sudo aptitude install xchat
  • Windows users can download the .exe from here
  • Other Linux distributions might want to use their respective package managers.

Chatzilla Install

II. Fireup your IRC client

  • irssi users can open up a terminal and type irssi.
  • xchat users can open xchat via their GUI, or type xhcat in the Run Dialog box (the one you get by hitting <Alt>+F2).
  • Chatzilla users can open chatzilla from the Tools menu in firefox. Tools > Chatzilla.

III. Quick Connect

Before we go into lengthy nick registrations, complex commands and so on let’s just quickly connect to a server and join a channel, since this is what will suffice for most people anyway. There’s a bunch of commands you need to type, they’re the same more or less across the board. Ignore/close any dialogbox/popups you get for time being.

/nick TestUserOnALearnersLicense  
/server irc.freenode.net (or whatever your server's URI is)  
/join #python (or whatever channel you wish to join)  

And that’s about it.


Note to the reader: If this setup suffices for you then you can close this tab and leave right now, these are the basics and you can now hit the ground running. The rest of this document details other things that you will find are worth your while during your stay in the world of Relay-Chats, so you still might want to go through the rest of it anyway.


IV. Detailed Connection

TODO. This section will provide a slighty more detailed, client specific and less hand-wavy guide when it’s done. Just make-do with Quick Connect for now please? (wink)

V. List of really fequently used commands

  • /nick your_nick : Change your IRC nick.
  • /server your.server.url : Connect to a server.
  • /join #channel-name : Join a channel.
  • /quit : Quits. Obviously.
  • /msg someone_else's_nick Hi : Private message someone. (This opens up a new window once the other party responds)
  • /away afk : mark yourself as away citing the reason as “afk”. It’s curteous to mark yourself as away, when you’re not around.
  • /away (or /back) : An away command without an explanation marks you as not-away.
  • /names or /userlist to get a list of users on the current channel.

Caveat: xchat is silly and doesn’t use the /away reason, /away toggle strategy, instead it uses the /back command to mark you as back, form an /away.

VI. List of common servers

Freenode isn’t the only IRC server there is, there are bunch of others. I’m listing out a few so that people aren’t confused when they go to freenode and don’t find the channel they’re looking for. You might need to join the correct server.

VII. Registering your Nick

Why?

Nick registration serves a bunch of purposes, namely:

  • It gives you an identity, people can recognize you from.
  • You can join channels that require a registered nick, #python, #fedora are examples.
  • It safegaurds and reserves your nick (the one thing people identify you with) on IRC, so that people always know it’s you they’re talking to.

How?

Like everything else in IRC, it’s just a bunch of commands, you just need to run the commands to register your nick once for a given server. (Say freenode) This is the general list of steps you need to follow to register your nick on most servers:

  1. Think of a nick, switch to that nick. /nick <nick of your choosing>

    Caveat: If the server says something to this effect: “This nickname is registered. Please choose a different nickname, or identify via /msg NickServ identify .” It means the nick you chose is already registered to someone else, please try a different one before proceeding.

  2. Now that you’ve picked a nick, you need to tell the server ‘Nick-incharge’ aka NickServ that you want to register this nick for yourself, you can do this by doing: /msg NickServ register your_password your_email

    Caveat: Your IRC password is stored/transmitted/shown in plaintext, therefore please refrain from using an existing password that you’ve also used for other accounts.

  3. The IRC server should have sent you an email with a confirmation code and a command, simply copy paste that command into your IRC and hit Enter. You should get a confirmation from NickServ saying your nick is now registered.
  4. If everything goes well, your nick should now be registered. You should now get a message from NickServ saying:

    This nickname is registered. Please choose a different nickname, or identify via /msg NickServ identify <password>

    Now every time you connect to the server with your nick, you’ll want to identify your nick with the server, to do so you’ll need to run the following command: /msg NickServ identify your_password NickServ should now tell you something like: “You are now identified for your_nick”

VIII. IRC Etiquette

There’s some basic etiquette that’s considered in good taste, keeping it in mind, and using your common sense, will usually save you from commiting a faux pas. The list:

  • Please don’t expect an immediate response, waiting times vary from 15 minutes to over 24 hours at times depending on channel traffic, timezone and holidays, weekends and so on. If you’ve got things to do, let the IRC client run in the background and carry on with your other work. .
  • Pls dnt typ lyk dis!!!1 , You won’t be taken seriously. Ever. .
  • Don’t PM (i.e /msg some_user) without asking for the user’s prior permission on the channel, it’s considered rude by some people and generally not welcome without good reason. .
  • Be considerate of other people’s time-zones. The US is roughly 11:30 to 13:30 hours behind Indian Standard Time, Europe is roughly 4:30 to 6:30 hours behind IST, while Japan is roughly 2 hours ahead. What’s morning for you is probably not for the rest of the world, act accordingly.

IX. Follow-up

Automation

Almost all of the setup Nick, UserName, identify with NickServ can be automated in any decent IRC client. So that you don’t have to type the bunch of commands everytime.

“That shall be left as an excericse to the user.”

Note: for those of you who’ve decided to use irssi, I’ve got the setup procedure outlined here.


Please let me know of any discrepancies, typos you might find. Suggestions for improvement always welcome.
Date: 21 January, 2014.
Author: Anhad Jai Singh

OpenSource in a nutshell

Open Source… Opening the source… Source is open… Sourcing the Open ? Wait, What ?!

Being the tech savvy college we are (in the most literal sense you can imagine) , it is most likely that you have heard about this buzzword a million times.

But, what in the world is open-source? It’s a question most of us foster for quite a few of our initial months here.
If you haven’t heard of Open Source software …, wait that can’t be, you must have heard and probably used Software with it’s roots in open source. Firefox, Android, Chrome, LibreOffice, VLC all these giants are open source or derivative of wildly popular open source software.

Free and Open source software is software, for which the source code or “recipe” is freely available. This means that anyone can download it, modify it and share it!

But fret not! The saga has just begun!
The world of open-source brings with it not only free, accessible, modifiable code, but a community of developers, a whole host of coding styles, and people from around the globe who work together to improve software and code as a community.

This philosophy of sharing, and working for the greater good has helped volunteers and budding students such as yourselves grow as programmers, developers and people.

This near utopian philosophy has spawned community programs like the Google Summer of Code, Gnome Outreach Program for Women and Open Source and LUG communities, not unlike our very own OSDG.

This article hopes to briefly summarize some of these concepts and in turn hopes to explain, if not light the spark that motivates so many of the OpenSource volunteers who shamelessly toil day after day to help the community that has given them so much. As a part of the community of developers working on a software product you get to create software that can impact anywhere from a few hundred to hundreds of thousands of users. You get the chance to work with some of the brightest minds of your day, Robert Love, Guido Van Rossum, Linus Torvalds might just be your co-developers! These are people who might feature in your personal “list of geniuses”, well now you get the chance to work with them! You will meet people who will can code in LOLCODE and Shakespeare (SPL), (yes, they’re programming languages) and you will get harassed by your mentor, who will obsess about the spaces in your coding style, but at the end of the day you got home and realize that you have met a crowd which wants you to and helps you to learn, innovate and appreciate. The feeling of satiety is unparalleled, and your work becomes it’s own gratification.
For those of you with a favourite language and for those of you who have a language that is your pet peeve, fear not for in the vast world of open source, there are plenty of languages in the sea, err source tree. From traditional development languages like C++,Java, JavaScript and PHP to cryptic languages like perl , and beautiful languages like Lisp and Scheme and our personal favourites Python and C, The FOSS community has you covered.

For those of you with slightly more materialistic tendencies (wink wink!), some of the perks that come with working in open-source projects include $5000 in cold hard cash (just the way we like it too!) and free EuroTrips to places like Florence(EuroPython’13), London(MozFest’13) and Brno(GUADEC’13). Ofcourse you have to be a little better than the average contributor to get invited to the trips. You’ll have to qualify for one of the open source Programs listed above (vis-a-vis GSoC, OPW), but you already knew you’d have to sing for your supper didn’t you?

Ok! Now that we’ve baited you (hopefully). You must be wondering how one needs to go about all this funny business of contributing to this wretched thing called OpenSource.
Here is when we come in, the OSDG. (clever us, all the baiting was a setup for this!).

OSDG or the Open Source Developers Group of IIIT-Hyderabad, aims to promote Open-Source culture inside (and dare we hope outside?) the campus.
Our sole objective is not just to get everyone to selected for GSoC or GnomeOPW (it’s bonus if you guys do though!), but to cultivate an environment that is conducive to passionate developers. And to this effect we hope to hold hackathons to facilitate creation of newer better solutions and foster a community which encourages collective learning, thinking and development as opposed to the undercutting competitive environment most of us are used to. We’ll also be organizing informative sessions, brain-storming sessions and hackathons so that you can implement your ideas, because you know as Mr. Torvalds says, “Talk is cheap, show me the code.”

“If programmers deserve to be rewarded for creating innovative programs, by the same token they deserve to be punished if they restrict the use of these programs.”

-Richard M. Stallman

On behalf of your friendly neighbourhood OSDG Admins,
Anhad Jai Singh.
Shivani Poddar.


“Software is like Sex; it’s better when it’s free” — Linus Torvalds

Git in a Bit!

Image

Working with Git for the first time in opensource can indeed be overwhelming! The purpose of this blog post is to make that experience a little less troublesome by covering some of the initial steps which every novice should find useful. Its pretty concise for a topic as elaborate as git, yet I try to cover as many bits as I can :)  The following finds it’s origin in my notes for Git and GitHub while I was scaling my first steps into the world of collaborative development.

Git && Github ~ What’s difference ? Don’t they sound the same??

While Git is a revision control system, a tool to manage your source code history,  GitHub is a hosting service for Git repositories.  So, they are not the same thing: Git the tool, GitHub the service for projects that uses Git.

Ok , Good so which one do I use?

There are usually 2 types of patches one needs to contribute with opensource (my experience is largely composed of gnome) :

First, are the ones wherein your project has a repo hosted not on GitHub but (say)  Gnome Repos for existing Projects .

In this case you don’t really have to worry about the GitHub part of this post (unless of course you want to learn it anyways ;) ).Here the git commands you would be looking for are (In order):

  • git clone <git-url-for-project-repo> : This command will create a copy of the repository you intend to work on in your local system (the first time). It is this repo you will be working on to test the changes you will later want to contribute in the codebase. 
  • If you already have a repo cloned then :

git fetch: This command updates your local copy of a remote branch. This operation never changes any of your own branches and is safe to do without changing your working copy.
git pull : This command does a “git fetch” followed by a “git merge” .It is what you would do to bring your repository up to date with a remote repository.

  • git add <name-of-file-edited-by-you> : This command “updates the index using the current content found in the working tree, to prepare the content staged for the next commit”, it also ensures that the ignored files are not added by default.

Yeah, sounds fancy, BUT , how do I check if some file is added or not at any point of time in my git repo ?

    git status is what you want to run here .

That shows me the file I added , I need to see the changes too, is git that smart ?

Turns out , it is .. git diff  is what you are looking for here.

Continuing with the bullet flow..

  • git commit -m “<commit-message>” : This command records the changes in the files earlier indexed(staged) to be “committed” into the history of the git repo.

Thus, you will use git add to start tracking new files and also to stage changes to already tracked files, then git status and git diff to see what has been modified and staged and finally git commit to record your snapshot into your history

So, I have the changes here, they work like pretty and I am proud of me . but, how do they get to the parent repo?!

Here is when we introduce patches. These are consolidated pieces of code you would attach to Bug reports in (here Bugzilla) or send to mailing lists to share the modifications you have with you in your local repo, and the ones which you would like to be integrated into the main source code of the respective projects.

  • git format-patch HEAD^ : This command generates patches suitable for being applied via “git am” , In the scope of this blog, I only describe the command given the one commit on a clean repo is being patched.

Thus, with the above workflow , you will find that you have successfully leaped the first baby steps towards git. I’d highly recommend going through branching and many more concepts which can be found in a great reference -> HERE

Thanks for the first way round , but too bad, I have a project which requires me to issue PRs (whatever they are ! )

Second kind of projects are those which are hosted on the web and have repositories in GitHub (for eg gnome-music :) )

While the first steps until committing changes in these are the same, the way a developer is required to communicate these changes to the co-developers varies a bit. After “git commit” , the workflow derails to the following steps:

if you have rights to change the master project repo (which is a little unlikely if you find this blog useful ;) ):  then directly use “git push

if not: you need to do the following :

  • Go to the “Fork” option on the extreme right of the webpage of the git repo and fork it
  • A copy of the repo in your github page gets created. This is where you will need to merge the changes from your local copy for you to request a pull request with the master repo of the respective project. The URL for this will be referred to as <your-project-fork-url> in the subsequent post.
  • Since a direct command to push into the master wont work , we need to first push it into our repo on Github and then request the maintainers to merge the changes with the project repo.
  • git remote add <remote-name> <your-project-fork-url> : This command will add another repository for the main repo to synchronize with.
  • git push <remote-name> master: This command pushes the required changes to your forked repository.

So far so good, but where are the PRs!! (Pull Requests)

The final step involves going to the main project page. In the right side column of the page is an option called “Pull Requests” , click it  < Click on the green button on top-right which says “New pull request” < select the base repo on the left-side (i.e. the project repo) and your project repo on the right < The required git diff is generated < Click “Send Pull Request”

(While choosing the repos you want to compare, one can choose other repositories other than just the master for the given repo. Thankfully the github ui is friendly enough to walk newbies through this !)

Voila ! there you go, bug the people on the channel to make sure your enhancements are merged ;)

Other advanced tools you might want to look at – git rebase, git gui, git mergetool, git branch, git stash, git fetch, git pull,git merge (and more as you go :) ) Hope it helps in “un-horrifying” the initial troubles with git and github.

Signing off :“Its not that I know too much, its only that I know what hitting the “?” key on any page in Github does ;) ”

~ Shivani Poddar

Android – Best Bet for Mobile Application Development

Hello folks, in this post, we will be discussing about why Android is the best platform to start with the mobile application development. We will be mainly talking about android and iOS development, as I don’t think windows is even near to any of these.

  • Open Source. To start off with, Android, as we know is an open source operating system. You have the freedom to download the whole source code and play with it, to use any code snippets you want from the source and many other uses. Owing to this fact, one of Android’s big plus-points is the continuous collaboration of various developer’s innovations, across the globe.
    Actually, that is not exactly the reason that would be appealing for you to start with Android, but it leads to several other entrancing factors.
  • Supportive Community. Being a new developer, you can find anything you need on xda forums or stack overflow. Both the communities are very supportive and always ready to help on any issue.
  • Developer Environment. Regarding the Android’s developer tools, leveraging Java and the Eclipse IDE are major winning factors for Android. Apart from the great Java and Debug perspectives, one of the striking features is Incremental Compiler, which provides immediate feedback with errors and warnings as you type. This is not available in Xcode(read as iPhone development).
  • App Deployment. The app submission process stipulated by Google Play is much less tedious than the iOS App Store.
    You submit your application with a description, set the price, and … you’re done! As soon as you’ve got the app written and submitted, it’s pushed out to a very large market.Whereas, in the case of iPhone development, the biggest problem for app developers is to get their app approved at the App Store. This process takes maximum time. Sometimes, apps are rejected for the slightest errors and this can prove to be very frustrating for the app developer. As an example, it took around 1 month for Opera to get their browser app approved.
  • Registration Cost. This is “THE” most important factor for the new developers. The initial cost of registration for the play store is only $25, which makes it much more affordable to the developer to submit apps to this marketplace, compared to the 99$/year for the iOS app store.
    Also, Google Play is the best when it comes to payouts; it pays you out just a few days after the month is over, and with apparently no minimum. Many other app markets pay about 30 days after the end of the month.
  • Google is Awesome! One more thing, Google introduced a new feature this year in I/O — “alpha beta testing of your app on the play store”. Isn’t that awesome! Now, you have a platform to test your apps as well. Google Play Developer Console lets you select your groups of testers either through creating a Google Group or Google+ Community

I guess these factors are convincing enough to get you started with Android Development 😉

-Yash Girdhar

Decorators in Python

If you’ve browsed some open source Python codebase, you might have come across statements/function definitions beginning with @. These are called decorators, and are apparently quite a useful feature in OOP.

Using decorators is quite simple, compared to writing one, and in one line, are used to alter the properties of a function while defining it. A decorator precedes the function definition, something like this:

@decorator
def foo(arg1, arg2, ...):
  pass

It alters the properties of the function, and is equivalent to writing:

foo = decorator(foo)

Python also provides two decorators by default, @staticmethod and @classmethod.

A function decorated using @staticmethod will have no knowledge of what class it belongs to, whereas a function decorated with @classmethod will always get the class it was called from as its first argument. A proper idea of when to use these and when not will require a greater experience in Object-oriented design and knowledge of design patterns.

Here’s an example – http://stackoverflow.com/a/16172278

So, the typical structure of a decorator is like this:

def decoratorFunc(decoratedFunc):
  def innerFunc(arg1, arg2, ...):
    # You now have the arguments. 
    # You can modify them as you like
    # before passing them to the actual function

    returnVal = decoratedFunc(newArg1, newArg2, ...)

    # Play with the return value, before returning

    return newReturnVal
  return innerFunc

@decoratorFunc
def decoratedFunc(arg1, arg2...):
  #Function body
  return returnVal

So, as you can see, the decoratedFunc has no knowledge of the fact that it is being handled differently, you intercept the arguments before you pass them to the function, then you call the function with the modified arguments, and then you intercept the return value before it reaches the user, make any necessary values and return it.

So, how does this work?

As I mentioned earlier, writing @decoratorFunc before the decoratedFunc‘s definition is exactly equivalent to writing:

decoratedFunc = decoratorFunc(decoratedFunc)

So decoratorFunc returns an innerFunc, which will call the decoratedFunc internally. The user can now no longer call the actual decoratedFunc, because its memory address has been lost to us. We have rather replaced it with the innerFunc which internally calls the original decoratedFunc.

A practical example:

If you’ve used Flask, you would have to define callback functions like:

@app.route("/home")
def homeFunc():
  return "Hello World"

So, when the client requests http://ipaddress/home, Flask executes homeFunc() and displays its response. Here’s the definition for app.route.

def route(self, rule, **options):
    def decorator(f):
        endpoint = options.pop('endpoint', None)
        self.add_url_rule(rule, endpoint, f, **options)
        return f
    return decorator

So, what route decorator does is, simply return the original function i.e. homeFunc without modifying either the arguments or the return value, but add the URL-function mapping to its internal data structures, thus saving the user the trouble of doing that. A neat application of decorators.

For more examples and detailed description of decorators, check out this link: http://simeonfranklin.com/blog/2012/jul/1/python-decorators-in-12-steps/
You’ll also find links to some resources if you want to dig deeper into this stuff.

Cheers
Ankush

Searching for an Answer

“I Google, so should you” *

When I asked Nehal J. Wani to write for this blog, I gave him the option to write on a lot of topics. He refused and stated that if he ever had to write a post, the aforementioned quote is all it would contain. It’s hilarious initially, extremely so, but then you begin to realize the wisdom behind those words. Google and other Search Engines have become so powerful and contain so much knowledge in today’s world, that almost any query you have can be answered by a couple of well constructed web searches.

So before you go up to someone and ask something, do quick search to check if the answer to your question isn’t already well addressed in the 13th comment of a post on forum.

Google and other capable search engines will, with the right amount of tweaking of the search operators, query terms and other search modifiers, get you the answer you were looking for, even if it’s the 13th comment on an unrelated post on a forum; or at the very least they will give you what to further “Google” for.

Got a compile error, don’t know what it means? Copy and paste it into Google, see what comes up, more often than not, the first couple of search hits will sort it out for you.
Have a phrase, that you know some of the words to, but can’t remember the full thing? No problem, Google’s got you covered with the ” * ” operator.

Searching is for all intents and purposes a life skill in today’s interconnected, internet proliferated world. It will serve you well in the pursuit of knowledge and is an essential tool in any Programmer/Designer/SW Engineer’s Toolkit.

If some or all of this sounds like gibberish to you, or if you’re not familiar with search operators and such, It is easily remedied. I’ve taken the liberty of doing the first Google search for you, so here are some links to get you started, and serve as follow up material to this post.

— Anhad Jai Singh

 
* This quote was Originally used by Ankush Jain, and all credits and rights of usage and/or ownership belong to him. 😛

Why Open Source for Students?

We can talk as much about the principles of Open Source and Free Software, the philosophy, why freedom matters, etc. This is important, but these are not the answers that most of the students are looking for.

Most of us eventually want to land a lucrative or satiating job as a software developer. Having a knack for problem solving and a passion to achieve it using programming is prerequisite to fulfill this desire. There are people who care less for a job but have a zeal for problem solving using programming. Open source is good for all types of folks.

‘Kay, I love programming, but how does Open Source help?

  • We do a lot of projects as part of the curriculum. On finishing, all that remains of the project is a plain description in the resume. Instead of this, you can open source your project and host it on a service like github/sourceforge.net. This way, you are opening your horizon to the whole World Wide Web, rather than confining you ideas to a few fellow students.

  • The Working Environment. The best thing I like about open source projects is the style of working in general. You learn how “actually” a software is built. Typically, every software company trains it’s employees how to work in such a collaborative environment. Trust me, employers want you to be productive as soon as possible, and your exposure to collaborative environment gives them the confidence to recruit you.
  • Responsibility. You hold the responsibility of making something which will be used by hundreds and thousands of people. Get involved in HFOSS.

  • Experience. In many situations, you are bound to work on technologies you have never played around with. Open Source projects give you the experience in such technologies.

  • Money. Participate in Google Summer of Code 😛
  • Fun. Yes, you read it right. Ask anyone who is involved, it gets better and better as you keep contributing.

On an ending note

A college student just like us once thought of developing an operating system kernel as part of his hobby. He released it as open source so that more people could use his code, analyse it and give feedback.

In a span of few years, major corporations like IBM started using that code and eventually recruited developers to extend it.

Today, all the big names like IBM, Intel, etc have developers under their rolls working on the same piece of code.

By the way, its Linux 😉

Somay Jain.

Oh God, Not Another Blog!

You can pray to your Gods and your deities and that won’t change the fact this blog is going to happen. Deal with it.

But Why?

The purpose of this blog is to disseminate knowledge.

Knowledge being a term too vague, we’ll be sticking to writing about Computers, new Tech, old Tech, Linux, Software Development, Software Tools, Free and Open Source Software, Summers of Code and Winters that are coming. In the remaining seasons of Autumn and Spring, we’ll be talking about anything under the Sun.

What is this really about?

It’s supposed to do the following.

  • Help newcomers learn stuff faster than we did.
  • Help Interested people get started with contributing to Free and Open Source Software.
  • Introduce new technologies and tools to people.
  • Help everyone learn, because frankly, I can go red in the face saying I know everything there is to know and you still shouldn’t believe me. I know wouldn’t.

How is this supposed to work?

This blog is an initiative taken up by IIIT-Hyderabad’s Open Source Development Group.
So it’ll be run by the same people. Who you ask? Well, that’d be Somay Jain, Chetna Gupta, Shivani Poddar, and me, Anhad Jai Singh.

Now I know I said run by “Us”, but what I really meant was maintained by us. We’ll be banking on people who’ve agreed (and been coerced)  to write for this blog as Guest Writers.

In addition to all this we always always always welcome random articles you’d like to send us about anything cool you did.

Anhad Jai Singh.