jeromegn

I've been building projects with Node.js (+ using npm), and here are my two cents:

- One of the best changes to npm was to install modules locally instead of globally by default. I wish jam also did that, global installs are troublesome.

- Isn't package.json going to conflict with my npm's package.json? I definitely don't want to polute my back-end's packages with front-end only stuff.

Basically, I'd like more sensible defaults. Change the package.json to some other filename and install packages locally by default. I'm also unsure why it would put files inside /jam, I don't want to change my configuration to use some obscur and badly named "jam" folder. I believe people like the vendor/javascript or public/javascripts conventions, that would be a better default in my opinion.

Otherwise, I like the initiative. In the past we've been using Jim (https://github.com/quirkey/jim) which works more like bundler. Now we just do it manually for lack of a better solution. I don't think this is it yet, but it's close.

Both seem to do the same thing. The syntax differs lightly.

I used it once while working with someone else's code, so it's difficult to say, but I like the "less modular" and simpler ways of Backbone.

I tried alternatives to Backbone after my initial (and collaborative) creation of Todos, and I could not find anything as light, as "out of the way" as Backbone.

Loving every moments of using it.

Glad somebody did that. At some point this was a goal for Backbone.localStorage, but I ended up working with other technologies and not being willing to make time for this.

Good work!

By the way, this is being actively developed: https://github.com/jeromegn/Backbone.localStorage

I was surprised this wasn't mentioned in the article because this is, to me, the biggest issue with dating sites: too many guys, too many messages to women.

I've seen some of my friends (women) sign up and get messages within an hour. Even with a barely filled profile.

DocumentUp creator here.

Cool project. Why can't we both collaborate on the same project instead and make it awesome? You seem to also be using CoffeeScript, eco, express and marked.

I have a few ideas about "Documentation as a Service", unfortunately I don't have enough time to devote to this project so it's kind of stagnating right now. Would appreciate your help.

So what made you create that?

Having purpose in life also helps. You'll feel excited to go do your thing when you wake up.

At least that's what works for me.

I'm thinking of adding an option to Bring Your Own Markdown. This has a few implications that I need to code for though.

I mean, being able to link to a specific point (like a H2 or H3) in the README and have the page actually scroll there. Right now I don't think it works (or at least it's completely untested.)

Good point. Noted here: https://github.com/jeromegn/DocumentUp/issues/2

I haven't. Just having some fun, built this to hone my front-end skills and because I needed it.

I needed it for one of my projects and so I whipped up this simple documentation generator. It takes your README.md and turns it into an easier to navigate documentation site. Meant to be used on a gh-pages branch.

There's still much to do. This is an MVP.

I agree that performances are bad on EC2. That's because of the overhead of virtualization.

It's not a "Big Scam" though, it's just bad performances. It still has lots of pros, instant deployment to name only one.

You're right about that. I hadn't considered it.

I'm curious about what could be a better solution while maintaining that perceived speed.

That's not an issue with the UI.

It goes without saying that mechanisms in the back-end need to be implemented in order for AUI to provide a great user experience.

For instance: - On error, an action should be retried. - Long-lived processes should be queued and upon failure, requeued.

Hopefully, the user won't reload the whole javascript app before this action is successfully completed and should never notice it failed in the first place.

It's not perfect, but I find that it is better. There's definitely work to be done on the error handling front. The UI should be able to clearly notify the user when something he previously did, didn't work.

I don't think that's true for most users. Coders might think of it that way because they understand the complexity of apps.

When an average user completes an action and sees the results instantly, he's not wondering if something went wrong, or if something is ongoing. They've already had UI feedback suggesting a successful result.

Don't focus on the end goal, focus on the journey. I'm a self-taught web developer (used to be a self-taught designer) and I learned my way through development by simply building stuff. I've had stable jobs for over 5 years now.

Once you've built some useful projects (I built Backbone Todos amongst other things), people are going to find you through them and contact you with opportunities all the time.

You've already started putting your work out there on Github, now you just need to market yourself a little better. a Github account isn't enough. Blog about your experience, build a Twitter following and other promotion techniques.

Maybe extract some smaller bits out of your bigger projects. Those are usually more useful and get more popular quickly. Abstract some of that application-specific code and release it. It's both an exercise in programming and marketing.

I built this thing as a learning experience.

Jeremy Ashkenas then proposed to make it open source as an example app so that people could learn from it too. I finally had a chance to contribute to open source (but I did not know it would be a significant contribution)

I'm just glad it's been picked up by so many frameworks along the way. I think this is in big part due to the fact that it had just the right amount of simplicity / complexity and is perhaps one of the most basic use case for a framework like that. The new "Hello World" first-timer experience.

I guess my comment (apart from the French part) applies to most big cities in Canada. Thanks for pointing that out.

"the people are friendlier" is too subjective though, can't really be sure of that.

Getting a position in a startup or open source team here isn't up to spoken language (unless like said early, it's customer facing). I think startups here prefer English. French is just that little extra (sad thing to say, but it's the truth).

Personal income tax may be higher, but the advantages far outweigh the cost.

I'm thinking about: free healthcare, extremely low electricity cost, cheap rent (pretty much half as much as SF's rent) and everything that comes with living in a major city.

RE French: Ever learned a new programming language to go work somewhere? What's the difference? You don't have to be fluent in French, you have to understand it enough to read signs (which are usually just street or landmarks names with a symbol). I see this more as a great opportunity to become a better candidate in the future - by knowing another language.

I completely understand your reluctance, but you have to look at the bigger picture.

Updated localtodos.com to reflect the changes + some additional styling.

Ah, that's a good one. I'll add that.

Since I'm no programming nor javascript wizard, I needed some help from Jeremy. I know my way around MVC since I've been doing some Ruby on Rails in my time.

My experience with more advanced Javascript is with MooTools, so I found it familiar to build Class-like objects. I rather enjoyed the experience and I'll be using it to replace the codebase for my more complex project.

The documentation is exhaustive and with that example app, annotated et al., it's even better. I also am very confident in Jeremy's skills as the project maintainer, he helped me a lot and has proven he creates great Javascript libraries.

The API seems stable enough. From Backbone 0.1.2 to 0.2, there weren't that many differences in the API, mostly nice additions.

A little backstory...

With the help of jashkenas, I created this app to test my implementation of Backbone.js for MooTools (http://github.com/jeromegn/backbone-mootools) and my localStorage adapter (http://github.com/jeromegn/Backbone.localStorage for those interested). It just so happened that jashkenas had been aching for a decent example app, so he reported it to jQuery and included it in the repository.

My own version of this demo is available here (with an extra sorting feature, and built on MooTools) http://localtodos.com/ (source: http://github.com/jeromegn/localtodos)

Hope you like it.

At first, I was loading the new tweet form inline. But since the client's code need to be injected in every webpage, because that's all I can do with the Safari Extension API, then I couldn't put the form inline.

Here's why: I figured any malicious site owner could add some javascript code to submit the form with any text they want. Therefore any website could tweet something in your name. This is really bad, so I took this approach instead.

Hey HN, I'd love it if you could give me feedback on my first little app. I did this on my own as a pet project. At some point it reached an acceptable state of stability and usability, therefore I launched it. It's a MVP for sure.

Any designer can create something like that in a few hours...

Dashboard design is not about the style, it's about the usefulness of the data and the usability, bearing in mind the type of data and the usages its users do with it.

I've seen those a few times in the past and it always strikes me: No one is going to use a dashboard, however good looking, if it's not useful. These designs seem to be created to allow for any type of information in any amount to be regurgitated on a single page. (which will probably be unused)

I was definitely talking about an interactive prototype of the actual design, not wireframes.

It's the step I usually consider when passing on the design to the development department. Sometimes there's much more needed to explain than what a static mockup or interactive wireframe can.

Yes, it works well for user testing, feels more real, especially with a fluid layout. That's something usually harder to test with static mockups.