Being that I just started my new job at Aptana, one of the first things they asked me to do is learn everything I can about Jaxer and to document that process. For those of you who don’t know yet, Jaxer is essentially and AJAX server. The very long story short is that you now have the ability to run JavaScript on the server-side (no more cross-site restrictions!), and along with that ability you get some pretty kick-ass API functionality that isn’t normally an inherent part of JS (such as built-in filesystem or database functionality). Essentially, you can now write the better part, if not all of your web apps in JavaScript. What’s even cooler is that you don’t need to give up the technologies that you currently use in order to implement Jaxer. I’ll be writing on how you can blend all these new and existing technologies in the near future (perhaps even make my screen-casting debut), but for now I want to talk about how to get Jaxer set up with an existing Apache install, specifically an XAMPP-based development environment.

Granted you can download a stand-alone Jaxer+Apache bundle, but if you’re like me, you want to be able to start seeing how it plays with existing web technologies (for me, that would be PHP). The other thing that you’ve probably already got (if you’re like me) is a test / development environment locally, and it’s most likely XAMPP (or something similar). Finally, if you’re slightly OCD like me, you like to have everything in one place, all nice and organized. Well, you’re in luck, because I’m going to show you how to get all of this goodness up and running. My examples will be for a Mac install of XAMPP, but the Windows / Linux methods will be pretty darned close. The only caveat with this walk-through is that it is written based on the upcoming 0.9.5 release (which will be out within the next week or so), and this is because it covers some important changes from the 0.9.4 releases. Now that we’ve got all that out of the way, let’s get into how we can get all this up and running. Read on…
Read the rest of this entry »

If you were to take a look at my resume, you’d probably wonder why anybody would hire me… In the past three years I’ve had 4 jobs. Luckily for me, every job I left, I left for a good reason, and I could explain those reasons to the satisfaction of the next employer. But I’m not writing this to talk bad about previous employers, but rather to share a little of the knowledge I’ve gathered along the way (and supplement that with other people’s of course). Of course, this is all mostly relevant to development jobs, but I’m sure other people could take from this what they will.

Reasons My Jobs Sucked

There’s a lot of nit-picky things I could say here, but I won’t, I’d rather stick to the broad topics…
Read the rest of this entry »

Yeah, that’s right. The fine folks over at 37 Signals (creators of Backpack, Basecamp, Campfire, and more) have decided to try a few different things to “be one of the best places to work, learn, and generally be happy”, namely 4 day work weeks. I’ve seen quite a lot of posting about this announcement in my travels, and I didn’t really want to bother posting it again, but I just can’t help myself.

It sounds cool enough, and they have some really good rationale behind it, but I personally don’t see the need for it. The way I see it, most of the cool companies I’ve worked for have just gone by an even simpler rule: Make sure you get your work done, and do what you got to do afterwards. Beyond that, if you or your employees are TRULY passionate about the work that’s being done, the work week becomes irrelevant. I know that I’ll personally get engrossed in a project when it’s something cool, and work on it every moment I have.

So, I think the better solution to keeping people happy is to not work on things that suck… as much as possible. If your projects aren’t stupid or a waste of time, then you won’t have to worry about productivity, it takes care of itself. Don’t get me wrong, I’m not really knocking these guys, it just seems like a superficial proposition. Most of us don’t have the money to play around three days a week anyway.

They do have some other really good ideas that I agree with like funding their employees extra-curricular interests and discretionary spending accounts. They’ve got a lot of good things to say, so why not check out their article and let me know what you think?

37 Signals: Workplace Experiments

I’ve been stuck in somewhat of a rut blogging / personal development-wise for the past months for many reasons, none of which are all that negative. While I have enjoyed my time working on such sites as Cellware and some other projects for the last 10 months, I feel like I’ve lost sight of a lot of things that are important to me in my life. To that end, it’s time for some changes…

What’s New

I’ve accepted a position at Aptana, and will be working on some pretty cool stuff with some of the brightest people in the industry. Look for a lot of really interesting and exciting things to come as I spend more time with them. This position will require me to move across the country (Florida to California), and I’m looking forward to a change of scenery (and lifestyle).

What’s more relevant to most of my readers (thanks to everyone who visits), is what’s going to change with my content. I’ve decided to go over every article I’ve posted on here, and get rid of anything that I’m not happy with. This will take me some time, so please be patient as I work through everything. My goal is to have nothing but great content up, and none of the other half-assed or weak articles that are scattered throughout. I’ve also changed the look of the site and upgraded to the most recent version of Wordpress.

What’s Not New

The thumbnailer project is still up, and I hope to be able to update it soon. If you came here looking for it, just check out the projects page, and you’ll find your way to what you need. I’ve also decided to wipe out all the comments I’ve received. As much as I love everyone’s feedback, it’s entirely too difficult to port these over from the old blog, so I’ve decided to start over.

I’m very happy to be able to get back to doing what I love… learning new things, working with developers that are like-minded with me, and writing stuff that (hopefully) ends up helping people out. I’ve said it a million times, I’ve only made it to where I am in large part because of everything I’ve learned from the community on the web, and I feel it’s important that I give back and help everyone out in whatever ways I can. Stay tuned, as I’m going to be updating a lot more often, and working on some really cool things!

Let me first start by saying that I’m currently working at a startup, and for anyone who’s ever done this, you know it sucks up a LOT of your time… in my case pretty much all of it. I’m not complaining by any means, I’m doing some of the coolest work I’ve ever done in fact! However, I just wanted to explain my little posting hiatus…

Anyway, on to the matter at hand. I have found myself in a position where I am writing scripts that may need to upload fairly large files. My scripts were timing out, and I couldn’t seem to figure out why. For the unitiated, there are some standard things that you usually do to both your php.ini and in your script in this situation:

• Set your max_upload_size in php.ini higher (it’s only 2M out of the box)
• Set your script timeout to never (set_time_limit(0); in your scripts… don’t do this in your php.ini)

However, it turns out there are some other php.ini config variables that you may need to look at:

• memory_limit - This may also be an obvious one to some people, but for those of you who don’t know, this restricts how much memory PHP is allowed to consume while processing. When working with images and large files, this needs to be upped to accommodate these needs.
• post_max_size - This was the one killing me, and it was a major “Duh” moment as well. If you aren’t allowed to create a large post, how can you expect to upload a large file?? This should be set the same as your max_upload_size.
• max_input_time - the time that the script should spend in accepting input. This is setting defaults to 60 seconds, and you will probably need to update this as well

That’s about it! Quick and simple solution to a problem that is probably pretty common.