croby
PhantomJS, Selenium, and Django: Headless Browser Testing for the Rest of Us
To me, this seems to only solve a corner case in the main problem of JS testing - testing the DOM without a browser. The first question that comes to mind is, is a DOM even useful in a headless browser when it comes to JS? For now, grant that we're only testing presence and manipulation of DOM elements and no CSS manipulations or accuracy -- which I'd argue is a decent case for testing. Now, testing presence and manipulation of DOM elements in the abstract isn't very useful, as different browsers might treat DOM manipulations differently. Using a headless browser that no one actually uses doesn't solve this problem.
I'd see a case for this in running something like QUnit[1] test that just test JS completeness, but again, implementations differ so testing in one environment that no one actually is using isn't good enough.
The only thing that I've come up with for a solution for actually testing JavaScript in a robust, real-world way is using QUnit and Selenium[2] to define the tests, with Testswarm[3] actually running the tests. This setup allows unit tests to be run against JS by itself (QUnir), mock interactions to take place to ensure bindings work properly (Selenium), and have these executed against real browsers in a distributed manner (Testswarm).
I concede that this isn't an ideal solution, and I wish there were more people working on solutions like Zombie.js that would combine all of these in one so that JS could finally be apart of our continuous integration testing. The only (sic) thing preventing this solution is that it needs to have headless, identical implementations of all the browser's JS engines and DOM parsers in order to be valid.
[1] http://docs.jquery.com/Qunit [2] http://seleniumhq.org/ [3] https://github.com/jeresig/testswarm/wiki
Re: Thoughts on Flash (A level-headed response to Jobs)
Now, if it only had a way to execute javascript....
What they're saying is build a business, not just a thing to flip. Focusing on the business will, even if you end up selling it to someone else, make it a better venture in the end, and more satisfying to you as a person.
Hacker News Top Headline Jetpack for Firefox
Processing Time - Processing Code Jam @ MIT
Being in the LA college at my school (we had both Engineering and LA schools on the same campus -- you could take CS from either side) I was exposed to a much broader range of topics that the rigid and intense engineering curriculum wouldn't have allowed me the be exposed to. I took a lot of Human Factors/Design courses in my last 2 years which gave me a new perspective on the CS that I'd been learning.
The takeaway for me was this: being able to see your CS degree in context of a broad range of other seemingly disparate topics ensures that you aren't narrowly defining what the degree can do for you. You can apply the degree creatively to a broad range of problems that aren't necessarily even taught in the CS department (or, for that matter, the Engineering school).
"In what ails Yahoo, design is a non-factor. Neither search nor online advertising, the real battlefields on which Yahoo, Google and Microsoft spar, are meaningfully impacted by how very good is Yahoo’s design acumen."
...
"By no means am I saying that design is without value. Rather, I just think it’s odd — and slightly disingenuous — of the champions of design strategy to fall silent when it comes to the failure of a company that’s very good at practicing it."
I think a better analysis here of Yahoo's design is its design failure -- they couldn't design search nor online advertising that succeeded, which are what make up the market value of a company like Google. As such, they weren't much able to compete with Google on the issue.
Its a bit silly to say design couldn't save Yahoo. It absolutely, without question could save them, they just haven't figured out how to extend their /interface design/ skills to be /strategy design/ skills.
"The use of HTML comments in scripts dates further back to a transitional problem between Netscape Navigator and Netscape Navigator 2. The latter introduced the <script> tag. However, users of the former would see the script as text because of the HTML convention that unrecognized markup is ignored. The <!-- comment hack stopped being necessary by the time Netscape Navigator 3 came out. It certainly is not needed now. It is ugly and a waste of space."
People use to turn off JavaScript because the web was new and people were using it improperly. Based on the proliferation of everything JS these days, it feels like we've overcome this barrier, just like we've overcome Netscape 2.
I also feel like the analogy the author makes between 'designing for accessibility' to 'using JavaScript' is improper. I think if the article criticized the usage of Flash, it'd be a different story -- Flash used to be completely inaccessible and it (still) requires someone to download a plugin for it to work. Even so, youtube and the myspace music player (both Flash) are still incredibly popular on the web -- despite that barrier to entry. Something to think about -- maybe prompting to turn on JavaScript solves the problem, just like saying you need to install flash solves the flash problem.
New Technology: Dynamic Resizing of Images
http://ajaxian.com/archives/new-technology-dynamic-resizing-of-images
The article goes on to say 'Well, it looks like Michael may have gotten his wish as Adobe has hired co-inventor Shai Avidan to their team.' As such, it looks like this promising technology will be integrated into a proprietary application/technology published by Adobe. I think it would be interesting to have this technology in the HTML 5 spec. <img src="image.png"...