Starting hacking on a project with Meteor is lots of fun. But things can become a mess very easily. Meteor does not have too much restrictions on how to organize our project files but it’ll be useful to know some of its ways.

“packages” directory

This is where all meteor and atmosphere packages are stored. And it’s a good place to store your own packages. If your projects contain any parts which does not change often and mostly independent from the rest of your project, you can create a package for that.

Another advantage of using packages is namespacing. Global variables you create inside packages are only available inside the package. Variables must be manually exported to other parts of your application using the package.json file.

If you’re writing packages, also try testing them using tinytest. It’s really easy to test with tinytest and it comes with Meteor by default.

“client”

TL;DR: Fork in Github is not as same as Like in Facebook. Github has Star for that. Fork only when it makes sense or you’ll end up with a few old repos. Forking can be really useful if you want to submit a patch to the parent repo.

When I first started using Github, just like many others I simply went ahead and forked each and every repository I liked on Github. But this makes no sense at all.

Fork because the site says “Fork me on Github”

When they say that they are actually asking you to contribute to their project with code, tests, docs or other stuff at Github. Simply forking the repo and leaving it like that is no use to them.

Fork to start a completely new project

When we create new products, sometimes it’s easier to start on something which already exists on Github although the final result is going to be different. Instead of forking, create a new project.

I think GIthubs F...

Sometimes it become necessary to use iframes when building some web applications. Often we have them hidden but sometimes iframes can be useful visible too.

For Node Knockout 2013, I was working with Meteorhacks on [Open Comment Box](meteorhacks.2013.nodeknockout.com). It’s like a self-hosted Disqus alternative. We kept the comments view inside an iframe to make sure it doesn’t clash with main website styles and for security reasons. The comment system is real-time. So, comments visible changes frequently and it required the iframe containing these comments to resize in order to avoid scrollbars.

If we’re on the same origin, one of the things we can do is to continually check if the scrollHeight of the child frame document body changes and update the iframe height.

(function (iframe) {

    var prevHeight = null;

    setInterval(function () {

Elementary OS is one of the most beautiful operating systems I’ve ever used. Usually I mod my OS extremely but for the first time, I left most of the OS defaults as is. The operating system UI is really minimal and if you use wingpanel-slim with auto-hide you can save even more screen space.

But when I enabled it in elementary tweaks, it worked after a few tries but never worked on system boot. Then I came across a blog post in UbuntuHandbook.com about customizing the top panel in elementary OS. But I’m more interested in a comment made by the author. He says, in order to make sure wingpanel-slim (elementary OS top panel) tweak work, we must edit an entry in Cerbere section in Elementary Tweaks app. Works perfectly.

It’s really easy to create a new empty git branch with no parents (AKA orphan branches). First create an orphan branch with git checkout --orphan newbranch. Now you can remove any files in the directory with git rm -rf * and finally push it to a github repository with git push origin newbranch.

If you create branch in Github it’ll create the branch from master (which is what you’re going to do most of the time). Sometimes it makes more sense to create new branches. Example:

• Documentations
• Code Rewrites
• Github Pages

I learned this a while ago from a Github Post.