21–30 of 30 posts
pdf link anyone? i could find on scribd, and the slides aren't showing for me (chrome 5.0, mac 10.5). thx.
Earlier quoted context omitted.
Why is it ironic? I wouldn't talk about the trouble of converting their source document to PDF, since PDF already is the standard format for publishing presentations. Every scientist I know who makes presentations in PowerPoint exports to PDF when transmitting them to other people, mainly to minimize version conflicts and people ripping off their content. PS and PDF are also the standard output of LaTeX. scribd exist…
> PS and PDF are also the standard output of LaTeX. Erm, I thought that DVI was the default output medium.
Somewhat OT: is it just me or does anyone else find it utterly ironic that scribd, a site dedicated to helping people avoid dealing with the PDF browser plugin mess, is intentionally going through the trouble of converting their source document to PDF just so they can display it in their viewer? There's dogfooding, and then there's this. I'm not sure what to make of it.
Why is it ironic? I wouldn't talk about the trouble of converting their source document to PDF, since PDF already is the standard format for publishing presentations. Every scientist I know who makes presentations in PowerPoint exports to PDF when transmitting them to other people, mainly to minimize version conflicts and people ripping off their content. PS and PDF are also the standard output of LaTeX. scribd exist…
Apparently this is true on windows. Works fantastically on Mac though, even iPhone.
Earlier quoted context omitted.
Why is it ironic? I wouldn't talk about the trouble of converting their source document to PDF, since PDF already is the standard format for publishing presentations. Every scientist I know who makes presentations in PowerPoint exports to PDF when transmitting them to other people, mainly to minimize version conflicts and people ripping off their content. PS and PDF are also the standard output of LaTeX. scribd exist…
The epic shittiness of Acrobat Reader 7 is just how scribd got traction -- they don't really give a shit about PDF viewers -- their raison d'têre is to be the Youtube of documents. Their Flash viewer is terrible (doesn't work at all on Linux) and their site is largely hostile to the idea of you actually reading the content. I had an involved email conversation with one of the founders after slamming their iPaper flas…
Yeah; I don't get that, although this item helps to explain why.
Earlier quoted context omitted.
Why is it ironic? I wouldn't talk about the trouble of converting their source document to PDF, since PDF already is the standard format for publishing presentations. Every scientist I know who makes presentations in PowerPoint exports to PDF when transmitting them to other people, mainly to minimize version conflicts and people ripping off their content. PS and PDF are also the standard output of LaTeX. scribd exist…
> PS and PDF are also the standard output of LaTeX. Erm, I thought that DVI was the default output medium.
Please, just link to the PDF, not to an idiotic site that puts a login barrier and other barriers around downloading the PDF.
Every time I land on scribd, I make a throwaway account (with mailinator or whatever), and use that to download the PDF.
Edit: ... and I can't help but notice the irony that breaking scribd, makes it more obvious to more people that just providing the data (in PDF, in HTML, whatever) is better than burying it inside scribd. Thus nudging the world in the right direction.
I'm sure Rails is great for getting an application up quickly, but once you get some traffic and the application gets more complex surely you'd end up hacking it so much you might as well have written from scratch in PHP or similar?
That article just confirmed that I made the right decision when staying well clear of Rails.
Earlier quoted context omitted.
Half of these are things that I could see doing quite easily -- for example, although I happen to know that "select count(*) from users where lower(users.user_name) = 'patio11'" will result in a full table scan on MySQL, that category of mistake is easy to make and has bitten me a time or three. And it is easy to miss if your testing methodology doesn't include "Now run it against a data set about as big as the produ…
I know you're making a general point here, but for the example given, I think it's generally best to refresh your dev data from production regularly (maybe after each large release). That way you're always testing on data 'close' to the current production state, which would help you avoid any data-related issues like this.
Previously I've worked in banking tech and this procedure was always followed (with data scrubbing), but it was also low risk since we were already on a secure network in a secure building.
For a startup with sensitive live data though, I can see why it's best to keep prod data out of test environments and therefore lower the chances of laptops being left unlocked or print outs lost that contain sensitive data. It's clearly a cheaper and better solution to keeping everyone in a secure building and limiting their remote access.
Who'd have thought that "knowing your code / sql" would be a problem when using software that writes most of it for you! I'm sure Rails is great for getting an application up quickly, but once you get some traffic and the application gets more complex surely you'd end up hacking it so much you might as well have written from scratch in PHP or similar? That article just confirmed that I made the right decision when st…
There are plenty of large sites e.g., yellowpages.com and urbandictionary.com (which switched from PHP) which are built using Rails.
Even if you have scaling problems that are around that of, say, Twitter, your application code still isn't your bottleneck; talking to your database is. No amount of framework (or lack thereof, as you propose/promote) will save you from the ramifications of poorly-constructed SQL.
Who'd have thought that "knowing your code / sql" would be a problem when using software that writes most of it for you! I'm sure Rails is great for getting an application up quickly, but once you get some traffic and the application gets more complex surely you'd end up hacking it so much you might as well have written from scratch in PHP or similar? That article just confirmed that I made the right decision when st…
No, this is absolutely not the case. There are plenty of large sites e.g., yellowpages.com and urbandictionary.com (which switched from PHP) which are built using Rails. Even if you have scaling problems that are around that of, say, Twitter, your application code still isn't your bottleneck; talking to your database is. No amount of framework (or lack thereof, as you propose/promote) will save you from the ramificat…
Surely the best defense against this is writing every query yourself rather than letting Rails do it? (As implied in the article).
My argument isn't Ruby execution speed vs PHP execution speed, it's Ruby writing it's own SQL vs me writing it.
I agree 100% that the database is usually the bottleneck, it certainly is for my site.