Subscribe: SonSpring
http://sonspring.com/rss/
Added By: Feedage Forager Feedage Grade B rated
Language: English
Tags:
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: SonSpring

SonSpring





 



Thoughts on Walgreens

Sun, 08 Feb 2015 15:20:01 +0000

Product Review TL;DR = If possible, avoid shopping at Walgreens. Note: I have hesitated writing about this because I wanted to give Walgreens the benefit of the doubt, sincerely hoping they would get their act together. However, their apparent ineptitude in even doing something as simple as handling an “unsubscribe” from their marketing email list – which I never signed up for in the first place – leads me to wonder if they ever shored up their data integrity issues. My complaints against Walgreens are twofold. Firstly, a somewhat serious issue, is their potential to mix up customers’ medical info. Secondly, admittedly only a minor annoyance by itself, is that they do not actually unsubscribe customers from their marketing emails. I would just mark all “@walgreens.com” emails as spam, but in the off chance we actually have to use their pharmacy again, I would not be able to receive legitimate notifications from them. Such is my quandary. 1. Customer Data Mixup (For context: We live in Texas.) In the summer of 2013, my wife receieved a call from an unknown number, so she let it go to voicemail. The message left was from a Walgreens pharmacy in Flagstaff, AZ. The pharamcist had called to inform us that our son’s prescription was filled, and that we could pick it up. Perhaps needless to say, this was a bit alarming to us, because we were not sure if someone was using our family’s info to have prescriptions filled in another state. She called the number that was left in the voicemail, with me cautioning her not to “tip her cards,” by giving that person any more info than they may already have, in case it was a social engineering phishing scam. After talking with the pharmacist for a bit, it became apparent that the only details Walgreens requires to disambiguate between one person and another is name and birthdate. There just so happened to be another boy with the same name, born on the same day, but living in Arizona. However unlikely, you could see how with the last name “Smith,” this is not entirely outside the realm of possibility. As it turns out, this boy’s father is a doctor in Flagstaff. We got ahold of his office, and he was livid. As a medical professional himself, he realized immediately the implications of pharmacists unintentionally divulging patient info. He said that he was familiar with this particular Walgreens, and would talk to them personally. 2. Repeated Spam Awhile ago, a chipper Walgreens cashier asked me: “Would you like a paper receipt, or should we just email it to you?” Wanting to be a good Earth citizen, I opted for the latter, dutifully filling in my email address. Shortly thereafter, I did receive a receipt via email. However – maybe this was somewhere in the fine print that nobody has a chance to read while hurriedly attempting to get medicine back home for a sick kid – I unwittingly signed up for a marketing list. That did not bother me terribly, because I know businesses nowadays are increasingly attempting to stuff their “value adds” into any availble customer orifice. As an aside, I chuckle every time I see a piece of physical mail that says: “Unique offer for Nathan Smith, or current resident.” When I received that first Walgreens marketing email, I just sighed and thought to myself: “Email me my receipt, indeed!” I clicked unsubscribe as with any other undesireable. Sadly, that seems to have had no effect, nor the eleven times I have unsubscribed since then… That, coupled with their apparent loose checking around customer data, leads me to believe that Walgreens is just another Sony Pictures hack waiting to happen. Those in charge of Walgreens’ IT seem to be asleep at the wheel, in terms of getting their systematic processes in order. This makes me distrust them as a customer, being uncertain as to how safe my data is in their hands. In Closing While I enjoy the convenience of Walgreens being the closest location to pick up various knicknacks and fill prescriptions, I do not feel safe making an[...]



Designers Who Code

Fri, 23 Jan 2015 00:16:50 +0000

Design Mic check. Test, test… Does this blog still work? It is crazy to think, the last time I used it was in 2011, whilst suggesting to my fellow designer friends that they ought to learn Sass. sonspring.com/journal/sass-for-designers Note: Even in 2011, my presupposition was that the “designers” I was addressing already knew CSS. If you had told me then that in 2015 we would still be disputing whether designers ought to learn to code, I would have been sad. Well, let me take a step back and address some of my 2015 thoughts about designers and CSS. Oh, and apologies to those reading on mobile devices. At the time of this writing, my own site is not yet responsive. The cobbler’s children have no shoes. But hey, while you are at it, check out Unsemantic.com. See, at least I know how to do responsive, right? Ahem. A few days ago, I posted some brief ramblings on Twitter about how the designers at TandemSeven are learning to code… twitter.com/nathansmith/status/557603260459388931 twitter.com/nathansmith/status/557603388360499200 twitter.com/nathansmith/status/557604708324741120 twitter.com/nathansmith/status/557604954085789697 As is often the case when speaking in an echo chamber, the words reverberated around the Internet, through the process of re-tweeting, replying, and having my words cherry picked in isolation. If you have not read those four tweets in order, go ahead… I will wait. A few people have told me that I seemed brash, or that they did not appreciate the hubris of my remarks. While I am not retracting anything, though I would have hoped for a bit more leeway around my off-the-cuff blatherings of 140 character increments, I felt I should clarify. I do think there will come a point, maybe it will take a generation, where (web) designers who do not know the basics – of how web technologies (HTML/CSS) work in tandem to achieve their visual designs – will metaphorically be in a tough spot. Yet, perhaps “left behind” was not the best phrase to describe it. I do not think the industry is there yet, but I see the writing on the wall, so to speak. It is not like we are all going to board some grand ship and set voyage without some segment of our peers. I certainly do not fancy myself the captain of such a vessel. I am especially not saying that I am the arbiter of who stays or goes. Heck, I think it would be downright tragic if any talented designers ended up excluded. I am not trying to be elitist. Personally, I would not ever fire a designer who does not (yet) know how to code, or not hire an amazing designer who cannot (yet) code. What I am saying is: I believe that doors which would otherwise be open to a designer, whom is yearning to further understand the medium, those same doors will increasingly be closed to someone who is not striving to learn the basics. Currently, I think knowing how to do prototype quality HTML/CSS is the tie-breaker between two designers of the same caliber, all other factors being equal. Note: I have had some people tell me that things are never that equal, or the scenario is based on conjecture. To that, I say: Of course. This entire “learn to code” conversation is itself ethereal. We are way down in the depths of introspection and hair splitting. In the future, I think that basic coding skills will be more like table stakes rather than a tie-breaker. “The buy-in is set at: design skills, and HTML/CSS.” “You must be this tall to ride the ferris wheel.” Etc. That sort of thing. Again, I do not fancy myself as that gatekeeper. Just survey the job postings that are out there now. I think you will find that HTML/CSS nearly always accompanies “designer” job postings. What we will probably see, though I make no claims to clairvoyance, is the phrase “preferred” gradually changing to “required.” Much like knowing only HTML/CSS ten years ago was sufficient to land a job as a front-end developer, nowadays companies expect proficiency in JavaScript. We see this with mo[...]



Sass for Designers

Sun, 28 Aug 2011 18:48:29 +0000

CSS For more on Sass, read The Sass Way and follow @TheSassWay on Twitter. Note: Throughout this post, when I say “Sass” I mean “Sass and Compass.” This is not a post saying… “If you’re still building websites without Sass, you’re doing it wrong.” This is a post saying: “If you haven’t tried Sass/Compass, please do before dismissing it.” My Lawn… Clint Eastwood in Gran Torino If you are anything like me, then as a designer you are also probably a bit of a curmudgeon, though perhaps you consider it perfectionism – and justifiably so. You have honed a specific workflow you adhere to because that is what works, dang it. Woe unto anyone who suggests you are not doing things in the best possible way, right? Yes, exactly! Except, well… no. I believe my first reaction to Wynn Netherland, when he told me I ought to try Sass and that perhaps I would see a boost in productivity, was something along the lines of: “Bah, get off my lawn” — a reference to the cantankerous character played by Clint Eastwood in Gran Torino. I came to realize that his suggestion was not a subtle way of saying “I know something you don’t know” (though he did), but more of a friendly nudge towards greater efficiency. He was just being a good neighbor, so to speak. So, I am writing this post in an attempt to get designers out there (who are also already CSS savvy) to try Sass and Compass. I aim for this to be the article I wish I had read when I was first contemplating Sass but (at the time) did not consider it worthwhile. I could not have been more wrong. FUD There seem to be a number of false assumptions that designers get hung up on when it comes to the topic of CSS preprocessors. I know such misconceptions exist because I myself had these doubts ruminating in the back of my mind, and have seen others express similar sentiment, without actually having tried Sass. I hope to clear some of those up here… Myth: Using the command-line is hard Using the command-line is inconvenient I must learn both Sass and Compass Sass requires me to know Ruby Sass requires a foreign syntax Sass only works in Ruby on Rails Sass is always white-space sensitive Fact: Using the command-line is not scary Using the command-line is infrequent Sass and Compass go hand-in-hand Sass doesn’t require Ruby knowledge Sass is just CSS syntax, with extras Sass runs on Ruby (already on OS X) — outputs flat CSS, to use anywhere Sass itself is white-space sensitive — SCSS is not, use either one Think of it this way… As a designer you have undoubtedly worked on some project using PHP, Django, Rails, etc. You do realize PHP is a recursive acronym that means PHP: Hypertext Preprocessor — don’t you? Somehow, it is perfectly fine to preprocess HTML for productivity gains. Why should CSS be off the table? Setup Windows: On Windows, you will first need to run the Ruby Installer. Linux: On Linux, Rails Ready provides several Ruby essentials – read more here. OS X: This “just works” on a Mac, because Ruby is installed by default on OS X. Gem Install Note: The ~ symbol is an alias to username on OS X and Linux. If using Windows, replace ~ with %USERPROFILE% in the following command-line examples. For the sake of brevity, and server language agnosticism, let’s say you want to use Sass on a flat-file HTML site. To install Compass, which comes with Sass, just open up your favorite command-line utility, such as Terminal.app and type… Windows: gem install compass Linux + OS X: sudo gem install compass Next… Actually, that’s it! Compass and Sass are now installed. New Project Still got Terminal open? Good, just a few more minor things to type. To create a SCSS project named “my_project” on your desktop, do this… compass create ~/desktop/my_project Or, to create a Sass project named “my_project” on your desktop, type… compass create ~/desktop/my_project -x sass Reg[...]



JavaScript Interview Questions

Wed, 08 Jun 2011 05:05:34 +0000

JavaScript I was perusing my list o’ RSS feeds this evening — Yes, I’m one of those people who still read RSS — and happened upon a list of JavaScript interview questions posted by James Padolsey. This reminded me that I had a few questions tucked away from when I was contacted by a Meebo recruiter a few years ago. I didn’t apply for the job, because I was working at the (now defunct) startup Viewzi, and I didn’t want to uproot from Dallas and move to California. Just for kicks, I asked the recruiter if it’d be okay if I went ahead and tried my hand at their code questions anyway. After which, the recruiter replied: You aced the puzzlers, well done! Are you sure you don’t want to be considered for our JavaScript / Front-End Developer position? If you ever have the itch to move to CA, be sure to let me know! Since a few years have elapsed since then, I am hoping that it is kosher for me to share these questions, along with the answers I provided… 1. When does div.setAttribute('###') not equal div.###? Answer: When you’re trying to set an element’s class attribute, IE has issues. Therefore, it’s better to use .className instead of .setAttribute(). There is also an issue with .setAttribute() and style in IE, so .style should be used. // Don't do this: el.setAttribute('class', 'foobar'); // Do this instead: el.className = 'foobar'; // Don't do this: el.setAttribute('style', 'color: #000'); // Do this instead: el.style.color = '#000'; 2. What’s the difference between these two statements: var x = 3; x = 3; Answer: The first puts the variable in the scope of whatever function it was defined. The second places the variable in global scope. It can potentially cause collision with other variables with the same name. Therefore, the keyword var should always be used when defining variables, and an anonymous function should be used as a closure if need be, encapsulating multiple functions which can share access to the same set of variables. That makes sure the variables stay sandboxed, accessible only by those functions which need them. 3. What’s the difference between: !!(obj1 && obj2); (obj1 && obj2); Answer: The first returns a “real” boolean value, because you first negate what is inside the parenthesis, but then immediately negate it again. So, it’s like saying something is “not not” truth-y, making it true. The second example simply checks for the existence of the obj1 and obj2, but might not necessarily return a “real” boolean value, instead returning something that is either truth-y or false-y. This can be problematic, because false-y can be the number 0, or an empty string, etc. Simple existence can be truth-y. A “real” boolean will only be true or false. 4. Write a one-line piece of JavaScript code that concatenates all strings passed into a function. (Note: Formatting added for readability) function concatenate() { return String.prototype.concat.apply('', arguments); } More on that here…http://sitepen.com/blog/2008/05/09/string-performance-an-analysis 5. What do these two examples have in common? Short Answer: Both create potential memory leaks, especially in Internet Explorer. Example 1: var obj = document.getElementById('adiv'); document.getElementById('adiv').ptr = obj; Long Answer: This is bad practice, because you first assign a DOM element to a variable, but then you assign that same element to a (nonexistent) property of the element itself. This creates a sort of circular logic loop, and will negatively impact performance. Example 2: function assignClick() { var el = document.createElement('div'); function handleClick() { el.innerHTML = 'clicked!'; } el.attachEvent('onclick', handleClick); } Long Answer: This example will only work in Internet Explorer, because it employs the proprietary .attachEvent() method. Granted, .innerHTML is also proprietary (now a standard), but unlike .attac[...]



HTML5 in Drupal 7

Sun, 22 May 2011 02:49:19 +0000

Content Management I have been meaning to write this post for awhile. A few friends have asked me to explain how to do HTML5 in Drupal 7, via Twitter. Another concerned individual, having found a passing reference to it in a book review, even emailed: “I urge you to start producing this post just as deeply as you explained basic 960 principles. How I enjoyed reading it. It was like a chat with a soulmate! It is a rare opportunity to read background on why things are the way they are. In my mental system, why is the key ingredient to know what are you doing.” So, without further ado, here it is… Intro Structure Aggregation Template.php – Section Template.php – Pruning Template.php – Minification Block, Field, Region, Views HTML, Page, Node Includes Conclusion Intro In addition to HTML5, I will cover how to remove some of the generated markup Drupal spits out by default, and how to override default system CSS. I will also provide a few tips on how to get some quick-win page speed boosts. Before we dive in, I just wanted to mention that this won’t be a comprehensive how-to on building a Drupal 7 theme. For the sake of brevity, I won’t be covering the HTML5 Tools module, which endeavors to add features like new HTML5 form elements to Drupal. Instead, I will focus on trimming the XHTML glut that Drupal still instinctively wants to include, stemming from its earlier days. Remember — back before the W3C declared XHTML 2.0 is dead, heralding HTML5 as the future — when we all used to put type="text/css" on tags, as if we’d ever used a