Comments for gnegg

Comment on About by Uyfgkrwg

Uyfgkrwg — Sat, 05 May 2012 01:22:20 +0000

We used to work together http://ofycefodig.de.tl nn bbs guestbook every time a wake up i see that beautiful face i front of me. MAN, im in love with her!

Comment on About by Txkhtjna

Txkhtjna — Thu, 03 May 2012 19:35:50 +0000

I work for a publishers http://jyjihoanu.de.tl japanese bbs photos yeah once a day it depends on how busy you are. sometimes do it just because nothing else to do.

Comment on rails, PostgreSQL and the native uuid type by Bill

Bill — Wed, 03 Aug 2011 16:07:55 +0000

I tried using your method and everything is currently working except for my RSpec tests. It fails every time the tests attempt to execute db:schema:load because uuid isn’t a recognized method in the ActiveRecord schema definitions. I noticed you said that you got yours working with db:schema:load, so I wonder if perhaps I am doing something wrong? I’m using Rails 3.0.9.

Comment on rails, PostgreSQL and the native uuid type by Bill

Bill — Wed, 03 Aug 2011 07:51:53 +0000

Would you recommend using uuids as the primary key if you are using Postgres with Rails or just using uuids for lookup? I’m developing a site where I want to sync data that can be created on multiple devices or the server and therefore need to use uuids, but am undecided about whether to use them as the primary key or not.

I have read this can cause problems with large datasets because “each new key will likely be inserted at some random position in the index. This incurs an overhead for the database as it needs to move data around in the around the index to make space for insertions.”

However, I have not confirmed that this is true or will severely affect the performance of postgres.

Comment on tempalias.com – learning CSS by Philip Hofstetter

Philip Hofstetter — Tue, 26 Jul 2011 15:20:52 +0000

You are definitely giving me too much credit as I didn’t to the design at all.

As I said in http://www.gnegg.ch/2010/04/tempalias-com-smtp-and-design/ this was the brother of my girlfriend’s work (http://www.richardhaydon.com/). I just took his photoshop mockups and turned them into code.

Comment on tempalias.com – learning CSS by Pali Madra

Pali Madra — Tue, 26 Jul 2011 07:15:23 +0000

Well done Phillip. You have done really well congratulations. I agree with you that knowing the code is different from implementing. At times I’m furious at the browsers for not having uniform support. No one (except the designers) realizes what a pain in the b*** they are.

I hope you keep doing CSS and HTML programming because you seem to be a designer who has a promising future.

Best of luck!

Comment on Google Apps – Provisioning – Two-Legged OAuth by Grant Goodart

Grant Goodart — Wed, 08 Jun 2011 16:17:25 +0000

“This is totally not true though as Google’s definition of “all” apparently doesn’t include “Provisioning” ” – That was the key to my issue. Thanks!

Comment on The return of Expect: 100-continue by Leandro de Amorim

Leandro de Amorim — Tue, 24 May 2011 19:19:42 +0000

Muito Obrigado (Thank you very much!).

PT-BR) Apesar de ser de uma data distante e de um idioma que não domino, me foi muito útil!

EN) Despite being far from a date and a language other than Domino, I was very helpful! (By Google Tranlate )

Comment on AJAX, Architecture, Frameworks and Hacks by Philip Hofstetter

Philip Hofstetter — Wed, 13 Apr 2011 11:01:29 +0000

As I said: I totally like both methods but for different reasons. Building a nice framework in JS can be hugely beneficial, especially when you are writing a desktop-y app like gmail or that project of ours.

Then there’s just too much UI stuff going to to easily apply the first pattern.

But if you are writing a news site or something like github where you just amend the page with some AJAXy effects but you remain, overall, a collection of pages, then it the other pattern isn’t as bad as I would have thought at the beginning.

Comment on AJAX, Architecture, Frameworks and Hacks by Alberto

Alberto — Wed, 13 Apr 2011 10:56:13 +0000

Ok, let’s clear up a couple of points:

- we both know that there is no silver bullet, nothing works fine in all cases, and thus it might very well be that the two architectures are just suited to different use cases.

- I never talked about graceful degradation. Whether we really need it depends on a lot of factors, but that’s a whole other discussion. There are cases in which you just don’t need it (think mobile web app, for example), and cases in which you could really do without it.

- let’s leave the word “pragmatic” out of this kind of evaluations please. It has no real meaning other than “Thing A works well for me”, to which is way too easy to reply with a “Thing B works well for me”. And we have seen (and developed) applications with both “styles”, so both are _pragmatic_. If you want to measure which one is more pragmatic, good luck

Now, for sure many of the tools out there are geared towards one kind of development, but that is only because people have done things that way until now, and those tools were optimized for those patterns.

That’s IMHO no reason to not explore other ways. And honestly, in my latest experience with building a REST API + a “pure javascript” client I never had the feeling that things were more convoluted or harder to achieve than we the traditional paradigm. Quite the opposite, the clear separation of concerns was (for me, totally subjective) a huge productivity booster.