stuffihavemade

Take a look at Derby (which is similar to Meteor) as well (http://derbyjs.com/).

I think it would be easier to take the best stuff in the node ecosystem and port it to Erlang than the other way around.

What looks sexier on your resume though: "Creator of backbone.js" (Not trying to pick on backbone since it's a great project, but you can read the entire source in an hour) or "Contributed to making AR 5% faster for certain queries"

I'd much rather see 10 people put their time towards making one project better, then seeing 10 people start 10 divergent projects with dreams of becoming the next DHH, but I recognize that there are other factors at play.

I totally agree. Derby (http://derbyjs.com/) and Meteor are the only new frameworks out that excite me. RoR is close to ten years old and has thousands of man hours invested into it. Does anyone think a new project that has some of the same capabilities, but lacks the ecosystem/community is going to gain signifigant traction?

That's what VB6 tried to be. We all know how that turned out.

The only vim plugin that I've used that's an acceptable vim substitute is viemu (http://www.viemu.com/).

I'd dial back on the shadows behind the themes. It makes the pictures look like they're glowing.

I've helped a friend take a house (that I'm living in) from down to the studs to finished in about two years. We both agree we would have been better off hiring a contractor for how much time it took.

No way can you change your own oil faster than one of those drive through places. Just going to the store to buy oil and a filter is going to take longer than driving through.

If it's fun for you though, it's a hobby and not a menial chore. If I was in your shoe cabinet situation, I would take a measurment, go to the salvation army, buy the closest fitting cabinet, and call it a day. Then, I'd spend the time/money difference on hobbies I find fun instead.

To me, the most valuable resource is time. Sure, the epoxy might be only 5 dollars, but it might take me half a day of valuable weekend time to fix the problem correctly. Or, I could have had paid the plumber and used that same time to doing something more education/interesting.

I won't pull out the old Dijkstra quote, but I hate screwing around with hardware/os problems. The solutions to those kind of problems is almost never interesting to me. "Oh, foo should have been bar in that config! I'll definitely remember that when a similar problem occurs 5 years from now!"

To me, that's not a compelling reason to avoid using npm. I haven't played around with node that much yet, but Rails uses ruby gems just fine, and it doesn't require require everywhere. Even if you do have to use require in some manifest file, that seems to be a small price to pay to interact with existing code.

The thing that concerns me about Meteor right now is that they seem to be fighting the use of the existing node ecosystem (e.g. not using npm, fibers) which makes it harder to use existing node libraries. Derby.js (http://derbyjs.com/) in contrast, build upon existing node components and plays nicely with npm.

Also, the conflict resolution library (https://github.com/codeparty/racer) that is used looks to be very cool.

Why the NIH package system instead of npm? That's the main showstopper for me w.r.t investing time into meteor.

I'm running into this problem right now with S3. I have a bunch of files on a cdn that I want to store in my bucket but (as far I know), I have to download them all to my machine before storing them. I'd love for the api to accept a URL.

I don't understand how writing migrations takes "weeks (if not months)". I can see "hours (if not days)". But, you still have a schema and migrations, they just exist in the application layer instead without a clear upgrade path.

fyi: webrick (the dev rails server) only needs to be reset for database changes. Everything else will show up with a refresh.

130 hours = ~18.5 hours a day, 7 days a week

I would never stop to think that the x's could be the same. The fact the {} instead of do syntax is used and the fact that the parameter is called 'x' instead of something more descriptive tells me that I shouldn't be concerned with the parameter itself.

I don't see the point of this. How is

  [10, 11, 12].map(&X.to_s(16))

more readable than

  [10, 11, 12].map({|x| x.to_s(16)})

? The motivation behind this (less temporary variables) is a non issue to me since the scope of such variables is tiny. In addition, this makes code non idiomatic and harder to read for anyone who hasn't used this gem, and adds another dependency to projects.

It's strange to bring up the point of loading session info from a template because "In scenarios where the latency is too high, the experience is simply horrendous. Remember, fast is good. Users want fast.", but then say "On a related note, I never find myself doing validations and that sort of thing on the client, as I find it a pain in the ass to do the double work of checking on both the server and the client. You should though handle errors coming from the server (API) and be informative enough through error messages." Either you're not checking anything until everything is posted back to the server, or roundtripping to the server for every field. Either way, not doing any client side validation is going to have a lot more noticable effect on UX than grabbing session info directly.

Please provide an npm package! In addition to the security, uninstall and versioning problems mentioned by others, not every one runs Debian and Redhat. If you provide a node package, anyone who can install node can install meteor.

edit: Any by not every one, I mean me, running ArchLinux.

You're doing it backwards. You didn't get to choose the language, you use whichever language has the best libraries/frameworks for your problem domain.

You might want to consider changing the lime green color background to something more neutral.

REMOTE [Full Time]

http://www.trackabout.com

apply at http://trackabout.theresumator.com/apply/njfPJu/Senior-WebMo...

TrackAbout is a profitable and growing software company providing asset tracking and rental services via the internet using a Software as a Service (SaaS) business model. Our customers use a variety of mobile devices to record the movements of their valuable assets. Data is stored and made available through our hosted web site and web services. Visit trackabout.com for more information on what we do.

We are experiencing high demand for our services and we are growing. We need great people who are interested in playing pivotal roles in the growth of a small company. Our customer base is very dependable and we consider ourselves lucky to be doing well even in this soft economy.

We are seeking an exceptional and experienced developer who is truly passionate about technology and the craft of software development.

This is a full-time position, not a contract.

Our development staff is completely virtual (no office) and each developer works from home. We are not considering applicants outside the U.S.

You'll be working on all aspects of the TrackAbout offering including our ASP.NET website and web services, MS SQL Server and developing for various mobile devices. Your responsibilities will include designing and building new features, enhancing existing features, and fixing (gasp) bugs.

All members of our development team are dedicated to keeping up with the latest technologies, practices, patterns and tools related to software development. We take time out to share our knowledge with one another and improve both our skills and our distributed development environment. We often experiment with and integrate new tools into our environment. Some of the tools and technologies we're currently using include: ReSharper, Subversion, MassTransit, Jenkins CI, TDD with NUnit, VersionOne, MediaWiki, WCF, RESTful web services, RhinoMocks, Ninject, NHibernate and jQuery.

Required Technical Skills:

    Building web-based applications and web services
    Object-oriented programming fundamentals
    C#
    ASP.NET WebForms (MVC in the future)
    HTML/CSS/javascript
    MSSQL programming skills (sprocs, udfs, triggers, indexes, constraints, etc.)
    XML/XSD/XSLT
    Experience with SCM/version control

Nice-to-Haves:

    Experience with common OO design patterns
    Test-driven development (TDD)
    Mobile device development
    I18N and L10N development experience
    Experience in Agile environments

Since this is a work-at-home position, you'll be expected to be able work independently and unsupervised, but with clear goals and direction. We are quality- and results-oriented and we don't micromanage.

We look for the following:

    Passion
    Solid interpersonal, organizational and task-management skills
    Insatiable curiosity, a love of learning and a desire to continuously improve
    Friendliness
    Team-orientation
    Fanatical attention to detail

I really wanted Seaside to become a legit competitor to Rails. I think that the component/continuation model is awesome when you aren't building something that needs to support a million concurrent users. But, the Seaside ecosystem is (relatively) dead, and I can't justify reinventing the wheel for all of the plugins available for Rails.

I wanted a way to have stuff like this

http://stackoverflow.com/questions/1196031/evil-use-of-maybe...

be more abstract than defining extension methods all over the place. Unfortunately, my implementation is currently too slow for practical use (the time it takes to compile the lambda is too long, ~0.1 seconds on a relatively modern machine). I think that an evaling tree walker would be fast enough to make this project practical, but I haven't had time to implement it.

But what happens when QR codes aren't around in 20 years? You need another level of indirection!