HN user

hlidotbe

103 karma

[ my public key: https://keybase.io/hlidotbe; my proof: https://keybase.io/hlidotbe/sigs/JgbGHEZtC9gQAUp4-QxaWc8NoHTNgxLqtXWjPzb9su8 ]

Posts0
Comments34
View on HN
No posts found.

If you spent a few minutes to read RM's doc you'd have seen that RubyMotion runs on top of the Objective-C runtime. The only thing it "replaces" is the language, the syntax if you will. API, calls, parameters, ... all is native. This is not Adobe Air, it's Ruby on top of the Objective-C runtime. There's no translation involved, no interpretation.

The RubyMotion Way 14 years ago

Of course it's a shame that Laurent needs to eat and of course this has everything to do about RM being able to build for Mac or not. Knowing him, I know he would prefer RM to be open source but it would be much harder for him to monetize his efforts.

I'm perfectly ok with paying a fee to get RM but I know that wouldn't pay for support (especially if the community handles it which is already the case).

Corporate sponsorship doesn't always works and often lacks security and stability for both the developer and the project as they are at the mercy of one entity.

Since Laurent Sansonetti is the author of MacRuby AND RubyMotion, he already said feature from RM will be backported (and hence open-sourced) to MacRuby

As mentioned above, CocoaPods will probably be used for this purpose as it is already the de-facto repository for MacRuby.

I tried a bit, technically it works but currently you have to compile your xib to nib manually using ibtool.

That may have changed tough because I dropped the xib as I didn't really needed it.

I may have missed something but API calls looks like a regular Ruby call with a hash and since all [] are dropped it's systematically shorter (not even counting the fact that you don't have .h/.m, declaration/implementation, it's not just a matter of API calls).

i.e. [obj method: param second: param2]; vs obj.method(param, second: param2) which is exactly two characters shorter in ruby.

And what would be the point of having something that looks like Objective-C?

Having been part of the private beta I can tell you that it's a huge time saver. Objective-C is nice be ruby is much more expressive, you can use the same API with much less code, you can skip XCode altogether and use your favorite editor, ...

I can't express properly how awesome it is, really.

Here in EU, a lot of sharing or aggregating sites are beginning to censor themselves or are closing doors completely (videobb, mixture video, allotvshow, ...).

Most of the US series I used to watch online (no legal alternative except waiting 1+ year for an overpriced DVD set) are disappearing since MU shutdown.

QWERTY. I should be using an AZERTY French Belgian layout since that's what you get here but I switched a few years back because all shortcuts are first thought for QWERTY (curly and square brackets are specially annoying on an AZERTY layout)

Forget the centralized/decentralized stuff. At some point almost all git users have a somewhat centralized model.

You say you don't get it yet and I think it's the issue. Coming from years of SVN I was in more or less the same situation (but I choosed to switch so it was obviously less painful). Then I started playing with local branches and funny stuff like that. I can assure you that once you get yet you'll never wan't to go back :)

When is the "better" precision needed? Because the article itself says low/high 70's. This would translate to 20-25˚C. Who feels the difference between 72 and 73 (22.2222-22.7777˚C)? If you need precision, you will need decimals, in ˚F or in ˚C.

And I don't understand what does it mean to "not use all the digits". They are used, not just for the narrow range he cares about which is the comfort zone in his particular region of the world.

In Belgium it is between 15˚C and 25˚c all the year with few extremes on either sides. Nobody need 3 digits to tell if it's warm or not.

PHP Woes 16 years ago

Like thinking Intelissense is a language feature for instance, or trying to shoehorn an inherently web language into general purpose and complaining (it's doable, everybody does it but you have to accept it was not meant to).

We use Mercurial here. Easy, secure (ssh with keys) never forget files, small transfer size, possibility of committing regularly when the client has access to the files. With hooks, the update is done as soon as the changesets are received.

In some cases we can even create websites on the fly with a simple "hg clone"

I guess Git allows more or less the same workflow but Mercurial is easier for your designers.

We have one database server with SSD (we need more speed than room) and are pretty happy with them.

On a more personal note I use a Seagate Momentus XT in my Macbook Pro and this is the single best investment I made in years! This thing cost a third of a "real" SSD of the same capacity and for what an SSD is shining (boot time, application launch, ...) it's on par. The 4GB SSD cache is really improving the experience (they should offer an 8GB version though).

I can't recommend this enough if an SSD is too expensive or not capacious enough.

ok, if I understand well this is a competitor, smaller, slower with an inferior screen and touch technology and you have to (easily but still...) change its software to support those features given it's not build for it.

The only advantages being cheaper (I would hope so given the specs!), running Android (debatable) and using an SD card for storage.

Even the site lists more cons than pros...

We use Redmine here (~4 people) and it's great. Rails backed, lots of plugin if you need more and easily extendable.

It integrate cleanly with CVS, Git, Mercurial, SVN, ... and we'll even do invoicing with it in a few weeks.

There are paid hosting options if you don't want to maintain it yourself.