Thursday, June 25. 2009
You can’t maintain code you ... Posted by Paul Reinheimer
in PHP at
16:24
Comments (15) Trackbacks (0) You can’t maintain code you can’t easily understand
I just helped a co-worker with a problem in a sorting mechanism inside Javascript. Here’s the snippet that caught my eye:
var ret = (a.l > b.l) ? -1 : ((a.n.toLowerCase() < b.n.toLowerCase()) ? -1 : 1); I looked at the code, and stated: I don’t like nested ternaries, it’s too easy to mess up or miss something. My co-worker explained that the alternative was too long and drawn out, this is how it’s always done. I pondered the code for a moment, and asked what happened when a.l < b.l, as the case seems to be missing. That was the bug. The people I’m working with are all smart, great developers. We all miss things, tragically we’re not perfect. When you miss things, you need to be able to find them, writing overly complex code (I would consider nested ternaries an example of overly complex code) makes it really easy to find them. I’m slowly working on improving our internal coding standards document with additional rules, at the time being I’m considering:
Any other rules you follow? Note, while I am strongly discouraging the use of GOTO, I do not think adding it to PHP was a mistake. There are good use cases for the language construct, I just feel it’s an easy thing to fall back on when the real solution is to build your code in a more intelligent manner. Friday, June 19. 2009Hard to use paginators
If you have a lot of content, you likely paginate, hopefully to increase usability and decrease bandwidth bills, as opposed to showing me more ads. If you do, please use a paginator that’s easy to use. Here’s an example of a paginator that I don’t like
Why don’t I like it? Well, the two most common actions at this point are:"Go to the next page" and "Go to the page where content I’m looking for is likely to reside". Neither of those actions involves going to the last page (except by coincidence), and yet it’s the largest option by far. In fact the Last button section takes up 748 pixels (44 x 17), while the next button receives only 289 (17x17). I’m currently looking at an alphabetically sorted list of options. If I know that the types of items I’m looking for happen to start with "S" how do I jump there? Do I start on page 5? 11? 51? 101? Likely none of the above. Consider a pagination tool like the following. ![]() It’s clear what you’re looking at, you can move on to the next page, as well as jump to any logical position within the pagination system with ease. Now I know this is harder than traditional pagination systems. After all MySQL conveniently optimizes out calls to things like SELECT COUNT(*) FROM table;. Past that a quick bit of math and you know how many pages you need, and you can set offsets quite easily using a LIMIT clause or similar. When it comes to web development, or anything else "Where there’s muck, there’s brass". Just because a problem is hard doesn’t mean you shouldn’t solve it. Users like sites they can navigate (remember many users exhibit either link dominance or mixed behavior when seeking content), they reward sites they like with sales, more visits, links, blog posts, etc. Thursday, June 18. 2009
Memcached Constants - Lame Code Posted by Paul Reinheimer
in PHP at
14:40
Comment (1) Trackbacks (0) Memcached Constants - Lame Code
Please find below an incredibly lame piece of code to print out the values of all the memcached constants defined on their doc page. I was running into a few errors, and getResultCode() was obligingly returning the value of the constant, rather than the constant itself. I had to look up what that value meant. For some reason I couldn't reflect the extension to get the constants and values thereof, so with some lame scraping you get the following. Code under the jump, answers (as of our version of various libraries) here:
Continue reading "Memcached Constants - Lame Code" Wednesday, June 17. 2009
I don’t blame Iran or North Korea ... Posted by Paul Reinheimer
at
20:16
Comments (3) Trackbacks (0) I don’t blame Iran or North Korea for wanting Nuclear Weapons.
I think Nuclear weapons are bad. We can kill enough people with standard non-nuclear weapons thank-you-very-much, but, when you make a list of countries in the world that don’t like you, and most of those countries have them, it’s pretty easy to feel intimidated.
While the United Nations is writing strongly worded letters to Iran, it’s own security council has five permanent members: People’s Republic of China, France, Russian Federation, United Kingdom, United States. This list is practically a who’s who of nuclear weapon ownership. In fact, according to Wikipedia they have 8180 of the 8390 reported, active weapons world wide. Political instability sucks, the prospect of rogue groups within a government taking control of weapons is terrifying. But when you’re standing surrounded by people who don’t like you, and all of them have better designed, tested, and bigger guns than you, I can’t blame you for wanting to even the score. Wednesday, June 17. 2009
Does not making it faster make sense? Posted by Paul Reinheimer
in PHP at
14:27
Comments (4) Trackbacks (0) Does not making it faster make sense?
I'm currently looking at a project, and a few different optimizations for a project. The problem with most of them is that they will help out when the server is under light load, making it even lighter. Think something like adding etags to your server, when the file isn't changing often you save bandwidth. As the server gets busier, the file will be changing even more often, possibly approaching a situation where it's changing every time the file is requested.
My concern with a possible etag implementation is that it changes my load vs. users graph from being a simple line with a given slope, to an arc. Likely peaking slightly higher (doing that work isn't free), but with a much higher slope towards the right hand side. To be honest I'd rather have a flat graph myself, as it makes it easier to predict when things are going to explode. What would you pick? Am I just being lazy? Tuesday, June 16. 2009Strace
I run into issues all the time where I’ve installed an application on one of my various linux boxes, but for some reason it can’t find a library it needs. I end up getting an error message along these lines:
memcached: error while loading shared libraries: libevent-1.4.so.2: cannot open shared object file: No such file or directory I then do a quick search on my box, and find that that library is indeed available (even in a seemingly useful location), the application just isn’t seeing it. How do I tell the application where to look, or help it find it? Strace appears to be the answer. Simply run the command again, but through strace. You get output indicating all the different files it attempts to open. From the list you can determine where it’s looking for the library, and create a handy symbolic link there to the file in question.
Generally the application will look in many different places for the file, just create the symlink in the location that fits best for your system layout. Tuesday, June 16. 2009DPC Day 2 - The EndTuesday, June 16. 2009DPC Day 1 - Speakers Dinner
Procuring interviews proved harder on the first real day of the conference. The strange illness I procured crossing the English channel had taken hold. Much time was spent shivering.
(content-free) Untitled from Paul Reinheimer on Vimeo. Monday, June 15. 2009
Reinventing the Wheel or putting a ... Posted by Paul Reinheimer
in PHP at
14:55
Comments (9) Trackbacks (0) Reinventing the Wheel or putting a square peg in a round hole?
I'm currently working on a project that I feel will have me either forcing a square peg in a round hole, or re-inventing the wheel, both solutions seem… sub optimal.
I need to allow authenticated visitors to a website to chat to each other in a basic channel. They might need some light GUI stuff like making links clickable and that sort of thing. Moderators need the ability to revoke (delete) messages sent by users that they deem inappropriate, also send special notification messages to all users (likely they will simply be rendered in a larger font, possibly centered, but the fact that they’re "special" needs to be conveyed to the end client). As soon as someone said the word "chat" to me, IRC and XMPP came to mind. They’re both robust and proven ways to handle the chat problem. Unfortunately they don't seem to support deleting a message that was sent previously (a concept that may be harder to accept when you’re allowing connection from an arbitrary client application). Other bits like special moderator messages and such could likely be handled by hacking into the server implementation a few extra bits and playing with an open source client and hacking there as well. The servers are likely to be written in a language like C++ or Java, so while I’m comfortable editing to hack in a few things, there's not a lot of in-house talent to work on these (and I’d have no one to go to if I ran into problems). This all feels a bit like pushing a rectangle peg into a rounded rectangle hole. An alternative would be creating a simple PHP based server using either file, or memcached (, or something else) as a data storage system. Linking into our existing login infrastructure would be trivial: the code is already there. I have a few JavaScript chat clients kicking around, sprucing one up with the help of someone from our integration team shouldn’t be too hard at all. Our entire team would find the code rather accessible, as it's written in two languages we use frequently. This is all technology that we're already familiar with, and have demonstrated an ability to scale as our sites have grown. The problem is, I feel like something of an idiot writing the world's millionth chat application system. Thoughts? Which would you choose? Thursday, June 11. 2009DPC - Day 0 Christian Wenz
A quick conversation with Christian Wenz. Also: Content!
DPC - 0 Interview with Christian Wenz from Paul Reinheimer on Vimeo. Thursday, June 11. 2009Dutch PHP Conference Day 0
A quick interview with Rob Allen
DPC Day 0 - Rob from Paul Reinheimer on Vimeo. Wednesday, June 10. 2009DPC -1DPC -1 from Paul Reinheimer on Vimeo. DPC -1 from Paul Reinheimer on Vimeo. DPC -1 from Paul Reinheimer on Vimeo. Monday, June 8. 2009Dutch PHP Conference Day -4
Uploading this video while at Sea! Uploading took nealry two hours. I'm hoping to get more videos, and videos with content up once I hit dry land and reliable interweb.
Vimeo is teh sux at the moment, it should be available here DPC Day -4 by the time you read this (and if vimeo isn't sucking) Sunday, June 7. 2009
Dutch PHP Conference day -4.5 ... Posted by Paul Reinheimer
in PHP at
17:02
Comments (0) Trackbacks (0) Dutch PHP Conference day -4.5 drunken adventures
internet is far too slow for the good videos, sorry. here's part two of last nights adventure
DPC Day -4.5 from Paul Reinheimer on Vimeo. Saturday, June 6. 2009
Dutch PHP Conference Day -5, part 1/? Posted by Paul Reinheimer
in PHP at
10:32
Comments (0) Trackbacks (0) Dutch PHP Conference Day -5, part 1/?
A conversation with Scott MacVicar about his upcoming talk and tutorial at the Dutch PHP Conference.
|
Who Am I?Hi, I'm Paul Reinheimer a developer working with PHP. I wrote a book titled Professional Web APIs with PHP back in 2006, and am currently employed as a Senior Developer for Mansef Productions. Formerly I taught some great online training classes for php|architect. I'm working on a new site called Watch Me Photoshop which has great Photoshop video Tutorials. My hobbies are cycling, photography, and travel. I frequently write about PHP or other related technologies. Feel free to subscribe to just the PHP feed if you're only interested in such topics. ![]() QuicksearchCalendar
CategoriesSyndicate This BlogBlog Administration |
|||||||||||||||||||||||||||||||||||||||||||||||||
