Faulty 2012 Mac Mini? Tim ... get on it, will you?

I've just emailed Tim Cook about the 2012 Mac Mini being an unfinished product, based on my experience of two sub-standard units over the last five days.

Hi Tim. Hope your day has been good to you.

I purchased an updated Mac Mini (i5) last week and noticed that display output from it was unusual (both on a monitor and an LCD TV - both Samsung). Grey on a white background did not appear on the screen, fonts were grainy and the screen was overly bright and under contrasted. This issue occurred both from the built in HDMI port and a Moshi Thunderbolt to HDMI adapter. A 2011 Macbook Air I own displayed perfectly on the same monitor and TV using the same settings.

I took the item to a Genius bar in an Apple store and after performing some troubleshooting and diagnostics they agreed that the output was odd and that it must be a hardware fault and so promptly swapped my Mini for a new one.

The second Mini has exactly the same problem. Interestingly, when booted from Windows / Boot Camp the output to my display is just fine. Further, this is not a new problem, having been picked up on Apple Support Communities in July 2012 on 2012 Macbook Airs using an external screen (https://discussions.apple.com/thread/4080525?start=0&tstart=0). OS X updates and an Air firmware update subsequent to July 2012 have not corrected the problem.

This problem would have only sporadically been picked up by Air users because Air users would sporadically use external monitors. But Mini users must use an external monitor and many of these are HDMI only (as is mine) so it seems that we are in possession of a product that is somewhat unfinished and somewhat unusable.

Hope this is of interest to you.

I'm sure he'll get back to me soon.

jQuery - do I really have an AJAX cache problem?

I don't often write about code - I am no coder - but I struggled with something for the best part of a day and I thought I would post this just in case someone at some point might find it useful.

I stumbled across jQuery after finding YUI just a little to big for me to get my mind around and I am glad I did because it seems simple enough for me to grasp. Anyway, I was using .load to call a SUB PAGE into a MAIN PAGE using AJAX. My set of routines that  something like this

  1.  MAIN PAGE calls SUB PAGE via .load. SUB PAGE has table for data entry and hyperlinks for kicking off SQL PAGE to execute relevant sql
  2. Following data entry into SUB PAGE (via MAIN PAGE), click on hyperlink updates database using SQL PAGE and then refreshes MAIN PAGE div that contains SUB PAGE

Well ... for hours I kept inputting data, then clicking the relevant links only to find that the MAIN PAGE div sometimes refreshed, sometimes didn't. F5 always worked though. So I was pretty sure I had a cache problem. So I stopped using .load and started using .ajax, using the 'cache: false'. I could see that .ajax was now suitably randomising the get url, yet still my MAIN PAGE div was not refreshing. I was certain I had a caching problem ...

But I did not.

Using Google Chrome's development tools - I could see that sometime my jQuery routine was doing exactly what it was supposed to do, i.e.

a) Click SUB PAGE; execute SQL PAGE; refresh MAIN PAGE div

And sometimes things happened in this order ...

b) Click SUB PAGE; refresh MAIN PAGE div; execute SQL PAGE

My code was written to do a), but because SQL PAGE took a while to execute, b) was actually what was happening. And b) was bad - my MAIN PAGE div was actually refreshing, but the SQL to update my data tables was not executing prior to the refresh.

Once I realised this, the fix was easy. Using .ajax, I implemented the following logic:

i) Click SUB PAGE
ii) Execute SQL PAGE
iii) Conditional on the successful execution of the SQL PAGE (using the 'success:' option in .ajax), then refresh MAIN PAGE div containing SUB PAGE
iv) I left the 'cache: false' in place, just in case

This fix works 100% of the time for my code

So if you are pulling your hair out trying to work out why caching won't turn off, just make sure that you actually have a caching problem and not the problem I have described above.

Good luck

5 ways to tell that a mens toilet has been designed by a woman

  1. The urinals are too close together

  2. There is nothing more disconcerting than rubbing shoulders when you are in the middle of both a private and delicate act
  3. There are an even number of urinals
  4. As an extension of point 1, there is such a thing as Urinal Chess. It goes something like this ...

  5. Move 1: take either the farthest or nearest available urinal, never the centre urinals

  6. Move 2: if both the nearest and farthest urinal is not available, take any urinal that leaves at least one between you and the next bloke (i.e. leave a space in between you and the next guy)

  7. Move 3: if neither the nearest nor farthest urinal is available and if no available urinal meets the constraints set by Move 2, use a stall (unless drunk - at which point Moves 1 and 2 hold but Move 3 goes by the wayside)

  8. If we accept these as tenets, then the following also holds true about urinal arrangements and their 'true' capacity for use

  9. As you can see, any even numbered urinal serves no increase in capacity and is a waste.
  10. There are more stalls than their are urinals

  11. Most of us men would spend more time standing up than sitting down. Please let that be reflected in the fittings and fixtures.
  12. The entry door is located so that it bangs the person at the nearest urinal
  13. If someone should walk through that door at the wrong moment, this can make things veeeeeeeeery interesting ...
  14. You can see heads over the stalls
  15. Men are taller than women, so stalls need to go higher than women's stalls. Otherwise ... well it can all just be a little disconcerting, really.