My grandparents are getting a digital photo frame for Christmas, they don't own a computer so the cat's not out of the bag. This digital frame has a stated resolution that's way off what you're looking at, the frame is like 16:9, but the pixel is... something else. I had a hard time working in Photoshop trying to prep the images for the system, since the pixels aren't square, they're rectangles, what looked good here looked like crap over there, etc. Then I found the pixel aspect ratio option under Image, created my own aspect ratio (using a ruler, and the pixel counts) and voila, I could now draw squares in photoshop that were square within the frame.
I still had a problem, when I converted existing images over to the new ratio, they got squished, it showed me a preview (which is all it really does), but didn't resample the image to look right under the new ratio. The solution is pretty easy, open up image size, turn off constrain properties then divide the width by the pixel aspect ratio and apply. Your image is now stretched. Then apply the pixel aspect ratio, and it should look normal.
I still had a problem, when I converted existing images over to the new ratio, they got squished, it showed me a preview (which is all it really does), but didn't resample the image to look right under the new ratio. The solution is pretty easy, open up image size, turn off constrain properties then divide the width by the pixel aspect ratio and apply. Your image is now stretched. Then apply the pixel aspect ratio, and it should look normal.
When working on any web development project, you have two central choices, Get it Right, or Get it Up. While the same choices dominate development as a whole, the low cost, high speed, and largely transparent nature of updates on the web make getting it up more tempting.
Getting it Right is what most developers strive for: clean code, easy to read, easy to use, easy to refractor. It's great, but it's not fast. I would even go as far to say that it's relatively easy to estimate how long it will take to develop something, but very difficult to estimate how long it will take to develop something "right".
Getting it Up (pun unintentional) is when you release just as soon as things work (mostly). You get the code working in some manner that vaguely represents what you're actually hoping for, push it live, then fix things as they break, add new features as they're required. It's faster, but you don't get to have that grand release party as soon as the application goes live, as you're probably madly mashing the keyboard trying to fix all the bugs that your users are finding.
(more after the jump)
For the re-launch of the php|architect website Marco and Sean chose to get it right. It took them a while (don't take my word for it, listen to the podcast archives for some original estimates on release dates) but they got it right. When it came time to implement a new feature like displaying shipping estimates without logging in first it was rather trivial (or so I'm told). They used their well developed code, tied into the existing structure, and added what was needed to display the information. For the launch of funcaday, I chose something a little... different. I Got it Up. The site launched, on the date and time I wanted it to launch. It didn't all work, oh gosh it didn't all work. But it worked enough that the visitors who came to the site saw what I wanted them to see. There was XSS vulnerabilities in public pages, various feedreaders didn't like that I omitted the optional GUID element from the RSS As these issues were reported, they were fixed. When time came to add a new feature such as actually posting an image over the weekend, adding a json feed, or supporting multiple image types it was a huge pain in the neck.
That's the issue with getting it up, you're often constrained by what you've already released. You can't move files, restructure URLs, or even re-factor public APIs (even something as simple as adding a new XML element can break third party apps). You're stuck. That's the principal issue of the "Get it Up" philosophy, you're forever constrained by decisions that were made quickly, lacking a full design to test them on. The balancing advantage however has two facets, while the site is up, you're gaining real world feedback on what people actually want. You can target your development efforts at the features that will have the most affect on your users, rather than your guesses on what they want. The second facet is revenue, most sites launch with some sort of bottom line in mind, while you're live you're gaining users, publicity, and hopefully whatever addition you were seeking to your bottom line.
When it comes to getting it right, you're constrained in other ways. You spend a long time (much longer than getting it up) tirelessly working to re-factor code that likely almost worked already. You probably can't share your code, problems or concepts too much with others (lest someone steal your idea and launch first using the getting it up philosophy). You don't get that real user-level feedback. You're also missing all the advantages your application will bring (financial or otherwise), since it's all taking place behind closed doors (or firewalls). Once your site does go live, it will probably stay that way. This matters, you only get launch publicity once, if your site crashes because it can't handle the load(since launch I've re-factored the code on funcaday to increase performance by a factor of 8), or you get hacked in the first twenty minutes, you're out of luck. You've burned your free publicity card on a launch that didn't.
Which one you choose depends largely on your needs and what's at stake. If you're running a real business it would be great to think that "Getting it Right" will always be the right and easy choice, but pressures like burn rate and competition are constant and tremendous. While the pressures to get it up are clear and ever present, just don't forget the disadvantages of that approach - you will either be forever constrained by those quick decisions, or forced to break URLs or APIs in order to change them.
Getting it Right is what most developers strive for: clean code, easy to read, easy to use, easy to refractor. It's great, but it's not fast. I would even go as far to say that it's relatively easy to estimate how long it will take to develop something, but very difficult to estimate how long it will take to develop something "right".
Getting it Up (pun unintentional) is when you release just as soon as things work (mostly). You get the code working in some manner that vaguely represents what you're actually hoping for, push it live, then fix things as they break, add new features as they're required. It's faster, but you don't get to have that grand release party as soon as the application goes live, as you're probably madly mashing the keyboard trying to fix all the bugs that your users are finding.
(more after the jump)
For the re-launch of the php|architect website Marco and Sean chose to get it right. It took them a while (don't take my word for it, listen to the podcast archives for some original estimates on release dates) but they got it right. When it came time to implement a new feature like displaying shipping estimates without logging in first it was rather trivial (or so I'm told). They used their well developed code, tied into the existing structure, and added what was needed to display the information. For the launch of funcaday, I chose something a little... different. I Got it Up. The site launched, on the date and time I wanted it to launch. It didn't all work, oh gosh it didn't all work. But it worked enough that the visitors who came to the site saw what I wanted them to see. There was XSS vulnerabilities in public pages, various feedreaders didn't like that I omitted the optional GUID element from the RSS As these issues were reported, they were fixed. When time came to add a new feature such as actually posting an image over the weekend, adding a json feed, or supporting multiple image types it was a huge pain in the neck.
That's the issue with getting it up, you're often constrained by what you've already released. You can't move files, restructure URLs, or even re-factor public APIs (even something as simple as adding a new XML element can break third party apps). You're stuck. That's the principal issue of the "Get it Up" philosophy, you're forever constrained by decisions that were made quickly, lacking a full design to test them on. The balancing advantage however has two facets, while the site is up, you're gaining real world feedback on what people actually want. You can target your development efforts at the features that will have the most affect on your users, rather than your guesses on what they want. The second facet is revenue, most sites launch with some sort of bottom line in mind, while you're live you're gaining users, publicity, and hopefully whatever addition you were seeking to your bottom line.
When it comes to getting it right, you're constrained in other ways. You spend a long time (much longer than getting it up) tirelessly working to re-factor code that likely almost worked already. You probably can't share your code, problems or concepts too much with others (lest someone steal your idea and launch first using the getting it up philosophy). You don't get that real user-level feedback. You're also missing all the advantages your application will bring (financial or otherwise), since it's all taking place behind closed doors (or firewalls). Once your site does go live, it will probably stay that way. This matters, you only get launch publicity once, if your site crashes because it can't handle the load(since launch I've re-factored the code on funcaday to increase performance by a factor of 8), or you get hacked in the first twenty minutes, you're out of luck. You've burned your free publicity card on a launch that didn't.
Which one you choose depends largely on your needs and what's at stake. If you're running a real business it would be great to think that "Getting it Right" will always be the right and easy choice, but pressures like burn rate and competition are constant and tremendous. While the pressures to get it up are clear and ever present, just don't forget the disadvantages of that approach - you will either be forever constrained by those quick decisions, or forced to break URLs or APIs in order to change them.
Working on funcaday I've spent a lot of time dealing with variables of the type resource in the past few weeks, after all GD images are held in variables of that type. I ran into some "functionality" of resources late last night that I initially chalked up to a bug, a variable of type resource went from being a resource of type GD to unknown while merely getting returned back a few steps. After some experimentation (and the inevitable epiphany while brushing my teeth) I've figured it out, and there's no bug.
Here's a longish snippet explaining what I was encountering:
Which returns something like:
(more after the jump)
The code causing the issue has a lot to do with some inner desire I've got to write clean code, so I explicitly destroyed the image when the object is destroyed (Gold Star, great memory management!) as you can see in the __destruct() method of the object. The real root of the issue here is how objects work. If this had been a string, there wouldn't have been any issue, the string would have been copied when I returned it (well, not quite, but it looks that way), and destroying the original wouldn't have had any effect on the one I'm dealing with externally.
But that's not how resources work.
Take an easier example:
You wouldn't expect the assignment $fp2 = $fp to open the file a second time, $fp and $fp2 both point at the same resource. When you close $fp PHP doesn't look around and check to see if you have any other references to that resource, it simply does what it's told and closes the file, any future attempts to use $fp2 will fail. The same thing is happening with gd in my example, when I explicitly destroy the image PHP does just that, it destroys the image, any remaining references now point to a defunct resource. The confusing part of my code is that it happened invisibly, __destruct() was called when the function ended (when the only reference fell out of scope) so it wasn't entirely clear that it was getting called.
One way to think of resources if you're having a hard time getting your head around it is to compare them to Objects in PHP5. Objects are always dealt with pass-by-reference, resources are similar.
Notes:
Thanks to Derick Rethans for helping me out in terms of determining that this was expected if confusing behavior. I'll be updating the resource documentation to hopefully go into this in some detail once the commit freeze is lifted.
Here's a longish snippet explaining what I was encountering:
class imageTest {
private $image;
public function __construct() {
$this->image = imagecreatetruecolor(2,2);
}
public function getImage() {
var_dump($this->image);
return array($this->image);
}
public function __destruct() {
imagedestroy($this->image);
}
}
function test() {
$x = new imageTest();
$image = $x->getImage();
var_dump($image);
return $image;
}
$image = test();
var_dump($image);
Which returns something like:
resource(3, gd)
resource(3, gd)
resource(3, Unknown)
(more after the jump)
The code causing the issue has a lot to do with some inner desire I've got to write clean code, so I explicitly destroyed the image when the object is destroyed (Gold Star, great memory management!) as you can see in the __destruct() method of the object. The real root of the issue here is how objects work. If this had been a string, there wouldn't have been any issue, the string would have been copied when I returned it (well, not quite, but it looks that way), and destroying the original wouldn't have had any effect on the one I'm dealing with externally.
But that's not how resources work.
Take an easier example:
$fp = fopen('file.txt');
$fp2 = $fp;
fclose($fp);
You wouldn't expect the assignment $fp2 = $fp to open the file a second time, $fp and $fp2 both point at the same resource. When you close $fp PHP doesn't look around and check to see if you have any other references to that resource, it simply does what it's told and closes the file, any future attempts to use $fp2 will fail. The same thing is happening with gd in my example, when I explicitly destroy the image PHP does just that, it destroys the image, any remaining references now point to a defunct resource. The confusing part of my code is that it happened invisibly, __destruct() was called when the function ended (when the only reference fell out of scope) so it wasn't entirely clear that it was getting called.
One way to think of resources if you're having a hard time getting your head around it is to compare them to Objects in PHP5. Objects are always dealt with pass-by-reference, resources are similar.
Notes:
Thanks to Derick Rethans for helping me out in terms of determining that this was expected if confusing behavior. I'll be updating the resource documentation to hopefully go into this in some detail once the commit freeze is lifted.
Sorry to everyone for the issues this evening, non-feed based users of the site should have seen everything up and working perfectly by 12:05am EST, while feed users needed to wait until almost 1:00am EST
1) Today's post posed a few issues, namely, it's the first weekend based post we've had so it's running through a different image creation path.
2) Since there's only one image for two days over the weekend, there's a whole bunch of code in various places to handle that.
The Real Issue:
I think I've found a bug in PHP. I didn't have time to develop a base case to prove it this evening (while the clock struck down towards midnight) but it seems as though resources can get mangled when being returned a few levels.
If you're interested in presenting funcaday to anyone through a project of your own, I'd reccomend taking a look at the json feed. Either json.xml, or funcaday.json. The information is identical in those two files, the difference is really just the extension, Technically if you're using JS the XHR object wants a text/html content type, so I provide the .xml version to get Apache to give you that header, if you're using anything else, go for the .json. Let me know if there's anything else you'd like to see in there.
One question for the mindful readers, in the RSS code I have:
Can anyone tell me why I would add the extra step? Do I actually need to do this, or is this just me following outdated practices?
P.S.
There's aparently a video version of funcaday by an anonymous... fan?
1) Today's post posed a few issues, namely, it's the first weekend based post we've had so it's running through a different image creation path.
2) Since there's only one image for two days over the weekend, there's a whole bunch of code in various places to handle that.
The Real Issue:
I think I've found a bug in PHP. I didn't have time to develop a base case to prove it this evening (while the clock struck down towards midnight) but it seems as though resources can get mangled when being returned a few levels.
Generating Weekday!
resource(532) of type (gd)
resource(532) of type (Unknown)
If you're interested in presenting funcaday to anyone through a project of your own, I'd reccomend taking a look at the json feed. Either json.xml, or funcaday.json. The information is identical in those two files, the difference is really just the extension, Technically if you're using JS the XHR object wants a text/html content type, so I provide the .xml version to get Apache to give you that header, if you're using anything else, go for the .json. Let me know if there's anything else you'd like to see in there.
One question for the mindful readers, in the RSS code I have:
file_put_contents('/path/funcaday.com/rss.xml.temp', $rss);
rename('/path/funcaday.com/rss.xml.temp', '/path/funcaday.com/rss.xml');
Can anyone tell me why I would add the extra step? Do I actually need to do this, or is this just me following outdated practices?
P.S.
There's aparently a video version of funcaday by an anonymous... fan?
I am proud to announce the launch of the funcaday project with my graphic design buddy Courtney Wilson. The goal of the project is to showcase a new PHP function each weekday, then a new concept, term, or technique each weekend.
I've got a project where I'm storing a lot of data in an object, and the object itself (through the use of a public method) returns the queries required to either insert the data the object contains, or update an existing record to reflect what it's storing. For a while I had a bunch of code of the (common?) but ugly:
But that's really ugly, and I've always felt that running the escape statement in the query construction line wasn't all that good. So I'm trying something like this:
Which is basically just duplicating all the properties of the object in a sql safe manner within an array. Then I can access the particular element within the array to dump into SQL rather easily, without the concat's.
What do you think, step forwads? backwards? a little sideways? How do you handle the problem?
$query = "INSERT INTO.... `description` = '" . mysql_real_escape_string($this->description). "'...";
But that's really ugly, and I've always felt that running the escape statement in the query construction line wasn't all that good. So I'm trying something like this:
private function sqlSafe()
{
foreach($this as $k => $v)
{
if ($k == 'image')
continue;
$this->sqlSafe[$k] = mysql_real_escape_string($v);
}
}
Which is basically just duplicating all the properties of the object in a sql safe manner within an array. Then I can access the particular element within the array to dump into SQL rather easily, without the concat's.
What do you think, step forwads? backwards? a little sideways? How do you handle the problem?
