div

So extending your analogy, you prefer travelling by truck over travelling by car ?

Just out of curiosity, which of the two platforms had the higher net number of conversions ?

It feels like this is very relevant especially since you think your next Adwords campaign will be more successful.

Sounds like you are violently in agreement on substance and quibbling over the wrapping.

Your argument basically breaks down to: I do all that stuff but use none of your fancy words.

That's great, spread your work methods around, many others are not as fortunate as you.

> We need better tools that let companies understand and budget for the cloud money they are already spending while at the same time letting end users sign up for the services they need to do their jobs.

This kind of tool would be aimed at precisely the market that would never pay for it.

If employees need to circumvent company policy to use Basecamp, the only way in which such a tool would be used is to identify culprits and get them back in line.

edit: on the other hand I would love a startup to prove me wrong :)

I love it when the output of print_r is larger than the html of a fully rendered page, by virtue of the html being included in the array you are printing.

No they can't see what circle you put them in.

They can see only your public posts, and posts you share with them or a circle they are in.

If they add you to their friend circle or their own ignore circle looks the same to you.

You can ignore individual people too.

Well, if it's beta, you are already showing it to people, so I would definitely show it to someone with a high chance of being a customer.

If they don't like it, you can always email them / call them to have a second look when you feel you've made noticeable progress.

EDIT: If using it in production carries a lot of risk for this customer, don't pussyfoot around and advise him to wait.

It's not as black and white as that for me, but that definitely does happen.

I find working from home 2 out of 5 days to be great for my productivity, while still being very available to colleagues.

I think a strong algorithm may surprise you.

I remember reading about the Netflix contest and how one of the algorithms categorizes movies into it's own statistically relevant categories*.

Once a comparative algorithm is used and the dataset gets large enough, I have no doubt the recommendations will start to get real good real fast.

http://devlicio.us/blogs/billy_mccafferty/archive/2007/01/02...

Google has contributed quite a few large patches to MySQL. I doubt they would be spending engineering time on improving MySQL if they did not use it internally for at least _some_ projects, and probably many.

Do a Google search for mysql google contributions and plenty of stuff pops up.

There's still a relational database there that will respond just fine to any well-formed sql statements you can throw at it.

If you use a relational database and believe you don't need to know sql, you're delusional.

If you are using a relational database, know sql, and want to eliminate a TON of boilerplate, use an ORM.

I don't know of many ORM's that claim "Use us and you won't have to know SQL". That's just a straw man argument.

If you define breaking down in the terms mentioned by the comment you are replying to, you are playing a semantics game to frame the debate to be: this ORM sucks because I can't use it without knowing sql.

>> It depends on the ORM you use

Yes, some ORM's are more flexible than others.

>> ... one of the pro ORM arguments is that it generates database-specific SQL ... portable between different RDBMS

Yes, hand writing SQL will break this but:

- it is rare in my experience to completely migrate to a different RDBMS

- migrating to a different RDBMS should easily be viewed by everyone from management to development as a very tricky process that will take time to perform correctly. Part of this time will be tuning your custom queries.

- the ORM promise that it's queries are RDBMS independent is not broken

>> Another point: your ORM would automatically pick up changes to your model and cope with it, not your hand-written SQL, making your code harder to maintain.

Writing everything by hand (known alternative 1 from the article) makes your code even harder to maintain because there will be zero changes that are automatically picked up.

Depending on the KV store you use, his second alternative may not have this problem.

TLDR: Hand writing sql comes with a cost, but the overal cost of "ORM + a bit of handwritten sql" is likely to be much less than "everything handwritten".

If you use the second solution mentioned in the article and just use only sql in your model, you would end up with a more varied amount of non-standardized data coming out.

The other existing solution provided by the author is to switch to a key-value datastore, which still would not solve your problem.

Yes, there is an impedance mismatch in mapping data from relational data stores to object instances.

This does not mean ORM's are an anti-pattern, or bad. ORM's provide a lot of value for the 90% use case that people often need to bang out under various time constraints (mvp, project for a customer, etc).

There is a trade-off when using an ORM that you, or your team, should be aware of. Once you start hitting the limits of what an ORM can reasonably do for you, it's fine to either:

- drop down to using handoptimized sql for specific queries / submodules of your project (e.g. a set of reporting pages) - figure out if you are trying to punch a cube through a circle by using a relational database over a nosql type storage, and consider moving part of your data to a different storage.

I haven't had a lot of experience with nosql databases yet, but I think it's also interesting to consider that relational databases have been around for a long time, and alot of corner cases where they are unwieldy are known. Nosql databases are not as vetted against reality yet, so abolishing one for the other may amount to nothing else than trading one set of problems for another.

It feels like people keep getting burned by investing all their stock into an ORM and then overcompensate by never wanting to use any ORM again.

ORM's are awesome to get things done quickly, but as stated in the article, and stated by those very same ORM's, you do sacrifice some performance.

As usual with these articles, there is a false dichotomy that one should choose between ORM or no ORM. It's a perfectly sound decision to use an ORM and hand-optimize whenever the need arises.

Also, ORM's usually _are_ optimized for the 90% use case, so going of on your own to write those in plain sql for your entire domain model is passing up on a huge amount of leverage.

Lobbying dollars at work.

One of the major pains when writing facebook apps is that their documentation is either incorrect, out of date or non-existant.

If you create a facebook app using heroku, it looks like you get something akin to a facebook-boilerplate app that is already deployed.

I would imagine the people at Heroku / Facebook spending some effort in keeping their boilerplate app / demo up to date with any api changes that may occur.

It's not really a boilerplate version, but there's a great answer on StackOverflow that keeps a list of pretty solid 3rd party libraries.

http://stackoverflow.com/questions/4078479/what-android-3rd-...

You are taking a risk of only being paid 1/3rd of your market rate for the next 6 months.

After that, you may be without a job. This is your downside, and it's what you should plan for.

In a best case situation, after 6 months you will start gradually earning back the money you missed out on, + a raise.

This means the only upside for you is the raise you _may_ get after 6 months. You should decide for yourself if you're comfortable with the amount of risk you will be taking for this upside.

As an extra caveat: it seems to me like it would be very easy for the founders to claim "there is no capital". Especially considering you are in a foreign country and are likely to not have any insight into the company's financials, it will be extremely hard and costly for you to prove otherwise if things go sour.

Why does getting billed not count as an interaction ?

Hacker news really isn't the best place to ask this sort of question.

You will receive a lot more help if you posted this question to stackoverflow.

It's always very painful if a codebase is not internally consistent.

I usually try to find some sort of dominant naming scheme to follow and clean up old code left and right, but yeah, sometimes starting anew can be the only sane thing to do.

Consistency and familiarity would both be good reasons to me.

Non camelCase variables and CamelCase classes in Java for instance would really feel out of place to me, whereas using the same case conventions for some ruby code would feel equally 'wrong'.

When it comes to conventions like this, I don't think there's a substitute for having a "when in Rome" attitude. If you're writing some greenfield code, Rome is all the other projects in your language of choice. If you're adding some functionality to an existing piece of code, that existing piece of code is Rome.

Did you just buy and convert a few admin themes that you now have shelved for future projects or is there some sort of workflow / tool you use to integrate these themes into your rails app ?

I just found out about install_theme (https://github.com/drnic/install_theme) which looks usefull.

Personally I've been using active_admin for simple apps, which has a pretty good theme, but there's not really much variation, if any.

It's perfectly normal to feel ill as a reaction to hearing something that upsets you.

If the author is not allowed to eat pork for religious reasons, I can easily understand him feeling ill.

If 2 viable solutions have this kind of long term vs short term trade off, technical decision makers need to talk to business decision makers.

Often it's reasonable to incur some technical debt with the short term solution, and then switch to the long term solution later on.

Delaying work gets you to market faster, costs less, and means you understand the problem better for less effort.

Obviously, if it's not a feasible roadmap to go with option a first and migrate to option be later, it's the techie's job to make this abundantly clear to the pm / business.

In my experience, when two viable technical solutions are presented, one is decided on by weighing the pros and cons.

The problem with 'appointing' a formal architect is as the parent said: the architecture becomes the sole responsibility of the architect.

There is plenty of room for a mediator without having to call him the architect.

I suppose to any newcomer my advice would be to go depth first into something like RoR or Django.

Learn the framework and learn the language really well, then once you're comfortable building things well (after a year or 2) experiment with something else on the side.

The hard part is figuring out what is worth learning, and for this a mentor can be priceless.

Agree completely.

You are simply not a well-rounded programmer if you can't architect an application / piece of functionality to do whatever it needs to do.

Designating someone to be the architect just causes strife / encourages 'normal developers' to shut up about architecture because there is no credit to be made.