We have a lot of images on our site and make use of the
img tag heavily to load up our assets instead of using
divs and setting a background image. What I learned and didn’t realize about until today, is that image tags are something called “replaced elements.”
What is a replaced element?
A replaced element is something that has its appearance controlled by an external resource. So what does that mean? It could mean that its behavior and appearance is controlled by the browser itself. This is why other replaced elements like
input all look different depending on which browser you use because how those elements are displayed is up to the browser.
On these replaced elements, pseudo elements like :before and :after don’t work, and aren’t meant to work due to their inherent responsibility and purpose. This behavior is directly mentioned in the spec. Too bad I didn’t realize it until I had already spent a few days wondering why my style works on a
div but I couldn’t find it when I tried swapping it to an
Note. This specification does not fully define the interaction of :before and :after with replaced elements (such as IMG in HTML). This will be defined in more detail in a future specification.
The workaround for to get my desired behavior is not difficult to achieve at all once you realize you can’t manipulate the
img tag directly. All you need to do is wrap your image (or other replace element) in a block element like a
div and then you can use the :before and :after pseudo elements to their full capacity.
I hope this information helps someone else out there who may not have known about this little piece of behavior in HTML!
This past Saturday I had the pleasure of watching the culmination of 8 weeks worth of work that went into the final projects of the students who took my class over at General Assembly. I saw everything from an aggregator of fitness clubs in the greater New York City area to a social trip planning web app.
I am always amazed and inspired by the things people dream up, especially people who may not have programmed a day in their life. Often, programming novices see the “web” and have no idea what goes into it, just “magic.” By having introductory courses like the one I teach at General Assembly, we begin to demystify the web so that students can gain a better understanding of the time and energy that goes into making a website or a web app.
Not all of the students I have taught or met want to become developers. Some just wanted to have a better fluency in “developer speak” so that they can go on to hire someone to finish up their prototype. One student and his wife want to start a business and he constructed a web application for potential customers to order window blinds. Many found that they were able to solve problems that they were having in their personal lives. A student in the class felt that she and other parents had difficulties keeping track of their children’s school activities. She developed an application to keep track of the school’s functions and be edited by her and other parents in the school to keep these events up to date.
When we as teachers, mentors, and role-models have a better understanding of what a novice’s goals are, we can better target how to answer their questions and frame it in the context in which they want to apply it.
8 weeks is not a lot of time to complete a full-fledged web application—especially when you’re also dealing with a full-time job and 3 hours of class time twice a week. I hope I was able to convey to them that it was really an achievement to go from no knowledge of Ruby and Rails to presenting in front of their peers their idea—even if they didn’t get everything they imagined completed. If nothing, they all learned to better hone what it meant to reach a minimum viable product and concentrate on the most important features.
It was a pleasure teaching you, and good luck in your future programming adventures!
During my teaching, one obvious effective tool for learning Ruby is the Interactive Ruby Shell (IRB). It helps students figure out how to play with Ruby’s syntax before they go on to write their first script. I’d heard about Pry before, but it wasn’t until lately that it came up on my radar again. Here is a small collection of links to blogs, resources, and screencasts that I have found helpful in understanding how powerful it is in development.
I can’t see myself using it just for a plain Ruby program, but it definitely is better than the basic Rails console.
I just use it like this from within the base of my project:
$ bundle exec pry -r ./config/environment
I’m in the midst of teaching an introductory 8-weeks course on Ruby and Ruby on Rails over at General Assembly in Manhattan. Per the course material, we have them install RailsInstaller, an “all-in-one” kit that is meant to get a novice developer up and running in a development environment as quickly as possible.
Acting as teacher, I felt it was good to lead by example and go through an installation of RailsInstaller. After I clicked the install button though, I immediately had flashes before my eyes of this tool over writing many hours of work of painstakingly pruning and preening my dot files, configs and preferences for RVM and git. I pretty much regretted that I did that, thinking it may compromise many of my personal and volunteer projects dependent on having a flawless development environment. (If you’re familiar at all with my Github profile, you’ll know that I have a few projects devoted to my obsessive collection of laptop configuration scripts and dot files.)
Honestly, I have been using my personal MacBook Air for a week now and haven’t noticed any issues in my development environment using the incorrect versions of Ruby, Git or RVM, but I still have this paranoid suspicion that I may have done something by installing RailsInstaller over everything I’ve curated. (Yes, very paranoid.)
Which led me to try to research on where RailsInstaller actually installed these files and how in the world I could remove them!
After a cursory search, I came up pretty empty-handed because on the RailsInstaller main page, it doesn’t give you any information on how to uninstall it! (Maybe a ploy for you to never uninstall it?? *cue evil laugher!*)
It seems Google Groups is the place to be for me in finding necessary information lately, so I came upon this thread asking about a “clean uninstall” for Mac OS X. (Finally!)
If you have an old version of RailsInstaller, you can run this simple command:
If you have a recent version like mine, that App doesn’t actually exist in that path and is actually within the ~/Applications folder. D’oh! (Now you know how often I actually peek into that folder versus using Spotlight.)
And there you go, it runs through a similar process that you ran when installing, except this time removing the files you previously installed and you can happily watch as all that extraneous overhead is removed over a cup of tea!
Like a lot of people I know who are on Macs, I use Growl for the different alerts I have set up on the different applications I use. For my IM client, Adium, I want to know when I get a new message and maybe know when my husband signs on or off. On Twitter, I want to see when I get a new private message and I use Propane to access my job’s Campfire and want to know when someone has mentioned something like my name or the work “Thai.” Growl recently updated to version 2.0 and I have encountered a couple of nagging problems.
Over the years, this functionality has become indispensable. I, like many people I know, either donated to the Growl project when it was free, or decided to purchase it on the Mac App Store whenever its newest version moved over to that platform.
That being said, I was really disappointed with some of the issues I have been having with Growl’s recent point release at 2.0 that came out a few days ago. All of a sudden, I noticed that I couldn’t click on the notifications anymore and have it open the appropriate application. When I see a new Adium message, I expect it to open Adium and show me that message. Instead, the notification pop-up would disappear into the GUI ether.
I insisted to myself that the problem just HAD to be user error and tried mercilessly to watch what it was that I was doing so I could debug. When that didn’t work, I then began to pour over the Growl preference panel to see if I may have accidentally unchecked/checked a box I didn’t mean to. No dice! There is no setting there that mentions any type of click behavior that could be modified.
My last stop was opening up the Mac App Store and looking at user feedback, I couldn’t possibly the only person experiencing this problem, right? Right. When I looked at the most recent reviews, ‘lo and behold, other users were having the same problem. A little more digging brought me to the Growl Google Group and latest gripes from the most passionate of users.
Another issue I encountered this morning was that roll-up and/or limits to how many Growl notifications appear at once also seems to be broken. As an example, when I logged into my account, Twitter was still running and was racking up notifications. I had to wait about a minute for the log to cycle through before I had access to my screen again, I’ve never had this problem before! Again, I don’t see a preference option for this, and it seems other people are experiencing the same issues. I don’t have “roll-up” enabled, because frankly, I only want those notifications if I am actually sitting at my desk, not later, but this could potentially resolve this issue. I’ll try again tomorrow morning to see if I encounter it again!
On Mountain Lion, I have the option of turning on Notification Center to handle my Growl notifications, but it gets grouped as a Growl application notification. That kind of sucks and defeats the purpose of quickly knowing which application is notifying me in the first place. I quickly turned this option off.
As a preface, I use Mac OS X Version 10.7 (Lion) at work and Version 10.8 (Mountain Lion) at home. Both had issues.
In this thread, someone complains about the Growl notification clicking not working. One of the fixes, or “workarounds,” is to download the Growl Version Detective and analyzing the different registered apps utilizing the Growl framework — I didn’t know this tool existed!
If you download the application, you’ll get a great bird’s-eye view of how each of your Growl-enabled application is using the Growl framework.
When you click on an Application name, you’ll either see an option to “Upgrade FW” (upgrade the framework,) “Revert FW” (revert to the original framework,) or a message stating that it can’t be upgraded because Growl doesn’t have permission to upgrade the framework because the application was downloaded via the Mac App Store. In that instance, the application developers will need to update their application to work with the latest version of the Growl framework and release that update in the Mac App Store.
An important change from version 1.3 to 2.0 was that Growl is now sandboxed. What does that mean?
In the Apple Sandbox Design Guide it goes over the importance of using sandboxing in your Mac apps. The idea is that you want to add additional protection to your apps and how user data is accessed. When Apple rolled out the Mac App Store, one of the biggest gripes from developers and users alike was the ability for low-level access to system functions to control more minute behavior and preferences. As designed, apps available through the Mac App Store can’t access root level privileges, nor should they as a safety concern! Apps that need that kind of access won’t find themselves in the App Store any time soon. That being said, Growl decided to trade off certain niceties and features so that they could offer their product in the App Store as well as having the additional pluses of having a sandbox.
That said, because of the sandboxing, it adds additional problems that haven’t been figured out quite yet, like the notifications not always opening the application after being clicked:
The old method for click feedback was using NSDistributedNotifications, which we could fire at any time, but these are not allowed under sandboxing with a payload (the context that we send back to the app would know what the click was in relation to). The new system uses GNTP networking, and eventually we have to close that socket, or we run into the problems that 1.3.x and 1.4 had with running out of socket slots and pegging a CPU, we do this after the display times out or 15 seconds, whichever comes first. We have plans on improving this, but we haven’t gotten that far yet. - Daniel Siemer
I will have to check back tomorrow to see if the “roll-up” option will fix the issue I was having with Twitter flooding my screen when I logged in this morning. I don’t have the option of upgrading the version of Growl framework for Twitter, so I’m hoping roll-up will work.
If you want to be able to use Notification Center with Growl in Mountain Lion, I would suggest you use a free product like Bark which will take the pain out of all the notifications getting grouped under the generic Growl App notification.
I have to wonder, now that Growl is a pay product, if enough due-diligence was taken to bug test this latest version. I can excuse these types of issues if it’s a free product because, hey — it’s a great tool and it’s free. But if I am paying for it, AND it’s available in the Mac App Store, isn’t that supposed to convey an additional expectation of quality?
If you’re upgrading your framework drastically between 1.3 and 2.0, shouldn’t there be some sort of notification to all developers out there to prepare for framework 2.0? I shouldn’t expect my users to dig through Google Groups (which by the way is apparently favored over filing a bug ticket in the first place!) to look for workarounds to upgrade something that developers should be responsible for.
These issues aren’t going to prevent me from using Growl, but it does make my experience less enjoyable and less useful. I would really hope to see that in the long-run that the Growl team take some precautions when making large changes like this and give users/developers more of a heads up or at least delineate known issues within the upgrade description on the Mac App Store.