Archives

All posts for the month July, 2014

Finding a current table of color laser Airprint capable multi-function printers (MFP) with prices and features is impossible. [If you are an Android user, just replace every reference of “Airprint” to “Cloud Print” since it is essentially a copy of Airprint, and would help Android users to find printers too] So, gathering info quickly to recommend a printer is laboriously slow at best. Adding Airprint capabilities to product page table lists and being able to filter by it (as “wireless” and “color” are valid filters on most company and shopping sites) would speed up information gathering. I only found out about Airprint coming to Xerox when I visited MacWorld Expo and asking a Xerox engineer. Worse, is this info has dropped Airprint off of HP’s list pages — but is at least still buried in each printer’s page in fine print.

When I spoke to the Xerox engineer he said some Color MFP under $1000 (for SoHo) and all Enterprise models had (or would have) Airprint, but looking at the official list today there was nothing to compete with HP’s $400 retail (~$300 street price) Color LaserJet M175nw MFP [now replaced by the M177fw] which offers Wireless print through Airprint — thus iOS devices can print without loading any software (and scan with software). Also, Canon had imageCLASS MF8580Cdw, at $600 coming out. At the show the Xerox rep, pointed out several sub-$600 Xeroxes that either had the feature or would get it with a firmware update. But since then, I have forgotten which ones those were. So, when someone shot me a quick email “Hey, saw that printer ____ and they told me to ask you about it. Which models would you recommend?” I looked it up, which led me to the first line of this post.

Airprint means that visitors do not have to go through an arduous process to print documents. No one has to call tech support, anyone with an iOS device can print simply by…

Continue Reading

Excuse any typos, but this is a seat of my pants post… I finished up one job last week, which led to time to refactor this proof of concept class while revising other work. Exterior demoes of these proofs get reactions akin to saying, “Wow!” But I feel like Oz, saying “pay no attention to the duct tape and zip ties holding up the curtain!”

When I say “proof of concept” I usually mean, if you look at the underlying code you realize the magic is in the amount of code smell (aka Bad Practices used) — which happens when I just sit down with an idea and just write something that works and best practices aren’t at the forefront. An analogy of this would be an artist sketching a picture quickly to just practice the art and exercise their perception-hand-eye-coordination. Another dev would see this stream-of-consciousness sketch-style coding, and think “that’s crap!” because trying to modify it would be a huge pain. And I couldn’t disagree, because modifying would be a huge job in comparison to writing new code.

However, It is times like these I like to reread this: http://stilldrinking.org/programming-sucks to remind myself that when I mentioned how I hate working with “crappy” code or incomplete documentation. 

Any time I do toss a stone at some crappy code, I get some snarky “this is where the magic happens” comeback, and sometimes even that venn diagram showing my comfort zone outside it. Yeah, guys… I get it. I realize that we are all guilty of it because of workload or time constraints — no one is perfect. There is only so much one can do in one session, even if that session is a solid 13 hours (which I have done before). So, I can either throw stones or TRY to develop better sketch practices with each sketch. This is what I have been doing the past week. I will write a class with comments, DI, patterns, etc. Then look back and see where the comments/structure broke down or when things got vague or messier. Things are improving, but they aren’t where I would like them to be.

But, does it really matter if my on-the-fly code is written poorly as long as it doesn’t crash? Probably not to anyone that might use it, but oddly I can’t get a voice out of my head that says this is wrong. If I want to see better examples from others, I should practice what I preach, and only release the refactored stuff, and things that don’t set off any code reflection warnings. Last week I only had the energy to write 3 base classes, each one had at least 2 or 3 code smell warnings. This week I refactored and got fewer warnings, but then the limits of the docs smacked me in the face, and things broke. I suppose this is part of the growing pains of learning how to use new tools. And then I bang on the problem until I either revert to a smell-but-working version or figure out what the documentation meant. This is when I re-read this: http://stilldrinking.org/programming-sucks so I don’t feel so bad about why I am not getting it.