tfinch

I've realized recently that (for me) mouse interactions come more naturally for more exploratory or creative work. I'm happy with my mouse! and yet for straight coding, or writing, I would rather keep my hands on the keyboard. It's fun to get good with all the tools(toys)!

So, they will be happy you have it, but will make you do all the questionnaires anyway.

It also has very nice bindings with haskell and nix

(BTW thanks for ansible, it's awesome :) )

I agree that it's a neat idea. I'm sure the content problem is why there aren't more attempts at the moment.

Warning, you may spend the rest of the day reading it...

Re: flow-state - perhaps the only game where this is possible at any level of intoxication.

(Shameless, but I'm still looking for an invite if anyone's got one....)

Are you going to add functionality for submissions? Or did I just miss it?

[1]http://www.python-requests.org/en/latest/

Not mine mine, it should be obvious. I'm not Kenneth Reitz.

In all seriousness, would be interested to hear about differences/benefits...

I recently spent a reasonable amount of time looking for a hosted CI solution that would run the particular version of postgis we use, rather than the 'latest and greatest,' but it seems like a lot of the current offerings have fairly limited flexibility in build environments (understandably I suppose.)

I'm keen not to make any comments about recommendations or the breadth of music available, as I'm aware that the latter is a chicken-and-egg situation, and the former is hard to judge without giving the site a chance to learn my tastes. I'm going to give it a try for sure.

And now for some classic hn nitpicks:

* Please stop your site links from opening pages in new tabs. Whilst looking about for more information, I ended up with 7 tabs open. Please no.

* I clicked on the feedback tab on the right side and was presented not with a feedback form, but a login form. If I can listen to music without signing up/in, surely I can leave feedback?

Personally I think it's entirely possible to work quite happily with both types of apps, once you realise the distinction. My typical approach would be to start (as mentioned elsewhere by others) with one project-specific app in the project (most likely called something generic like 'core') just to get off the ground. For some projects this may be all you ever need. All other apps involved are installed from pypi (or wherever) and provide some generic functionality that you are building off/with (for example, I imagine most people install django-debug-toolbar pretty much at the same time as setting up their project.)

Once a project grows a little, however, I think there's value gained in breaking out into separate apps. They can still have dependencies on other apps (for example relationships in the models) - it's just a way of breaking up the code into more manageable sections. Once you've done this for a few projects, or after working on a large project for a while, you might start to notice common patterns being used across the apps, or some block of functionality that is used all over the place, but doesn't really belong in any one of them - perhaps this might be worth having it's own app for. This might be the sort of app that you end up tidying up and releasing to pypi - but I see far too many people getting hung up on making all apps dependency free and completely generic, when they should be worrying about it working for their use case first! It's impossible to make a reusable and useful tool unless you've had to work through some/many of the possible use-cases (insert premature optimisation quote here.)

Here's an example of this approach, which hopefully makes it slightly clearer:

Imagine you are building a kind of multi-user cms for a particular type of content - your core app to begin with might contain a custom user model (because you're using django 1.5, right ;)) along with, lets say, 3 models for the dynamic content, like a page model, a chunk model, which makes up the page content, and a revisions model that helps describe the relationship between the two. Obviously all your views etc. all belong in the one app. Alongside your core app, you might install some 3rd party apps like django-guardian to allow more granular permissions.

Time moves on and you might start adding functionality like organisations. With the new functionality, users can belong to multiple organisations, and have several different roles, allowing them to edit other people's content or administer the membership of an organisation. Perhaps there is a review process certain content has to go through before it's allowed to be published and on top of that you want to have detailed activity streams to track peoples actions ("user x did action y to item z".) All of a sudden you have more models ( an 'organisation' model, a 'review' model and a collection of related models to do with the activity logging ) as well as some fairly complicated business logic to maintain the permissions system. Of course your views file has at least doubled in size as well as your urls.py file. Realistically this is still manageable but you can see where it's heading. It's at this point I would consider breaking it out into an 'organisations' app (including the organisations, users, and activity models, as well as their logic and views) and a 'content' app, for the pages, chunks, revisions etc. Of course the relationships between the users model and the page model (for example) still exists, but there is a fairly clear separation of interest.

Lets say further on down the road, you've maybe added more functionality, and expanded into another 1-2 apps. All of the users activity is tracked for all the different apps, so you start to think that the activity functionality and models could exist in their own app - just the models and the logic, which can then be tied into all other apps that require it. As you do so, and continue to expand your project, the 'activity-stream' app becomes suitably generic and flexible you feel it might be useful for someone else, and you release it into the wider world!

YMMV of course, this is just based off my experience, but maybe it will help other people getting caught up thinking about the distinctions. Also, I'm nothing to do with the 'django-activity-stream' app, it's just an example :).

[Edited for links] Fugitive: https://github.com/tpope/vim-fugitive

Some helpful screencasts can be found here between April and May 2011 http://vimcasts.org/episodes/archive

One nice project that came up on HN recently, but people may have missed, is codetriage (http://http://www.codetriage.com/) which I have signed up for, but have yet to take any action on. It provides a gentle run-way into contributing to projects on github, by emailing you issues from projects you have expressed an interest in helping out with. Even if you are not so confident in your coding skills, there is still plenty of helpful work to be done here. From the emails codetriage sends out:

  Goals of Triage

  Help share the weight of maintaining a project
 Minimize un-needed issues
 Prevent stale issues
 Encourage productive communication
 Teach good citizenship
 To become a better coder
 How To Triage?

  First, carefully read over the issue, title, and description, if there are any comments read over all the comments, carefully. If a member of this repo is engaging actively there is no need to do anything, leaving a comment in the issue would just add to the clutter.

  If the issue hasn't been updated in awhile, or if no one has commented consider the issue, if it is a bug try to reproduce it. If it is a pull request consider what an alternate implementation might look like. If there is something you don't understand about the issue and feel others will have that same question please leave your question in the comments. Be as descriptive as possible. Comments like "I don't understand this" are not helpful and counter productive. A better comment might be "Can you help me understand a use case for this?".

  If you can reproduce the issue or you believe it is a good pull request, add a comment and say why you think that is. Try to stay positive while triaging issues, ask questions before you :-1: something. If you do decide to :+1: or :-1: on an issue, leave a comment as to why you feel that way. Issues are for social coding, if you help someone make better issues, you're helping the community.

  If the issue goes stale, leave a comment asking if it is still a problem. If you get no response for a number of days, you can leave another comment suggesting to the repo owner that they should close the issue.

  Go forth and make the world a better place

Often with articles of this nature, the comments serve as a very swift mechanism to get corrections and bug fixes back to the author - improving the quality of the post for future readers.

On the point about automatic bookmarking, I would almost like everything I view to be bookmarked, and then some cleverness to work out what I actually will come back to.

I also third the requests for cross-device sync. (I'm sure you already know this will be needed at some point, and appreciate it's outside the scope of an initial version.)

I haven't tried Fuduntu, but may be tempted at some point, and I can appreciate the amount of work that has gone into it, but this review doesn't really sell it for me.