Saturday, October 18, 2014
Thursday, April 15, 2010
Google to open source VP8 HTML5 video!
Google to open source VP8 HTML5 video! http://newteevee.com/2010/04/12/goog...r-html5-video/ Google purchases VP8 and is planning to open source the technology. So what does this mean for the layman? It means that emerging technology called HTML5, specifically HTML5 video, can be supported by all browsers for free! Furthermore, this means that another nail is put through the heart of Adobe's Flash format, and thus may be sealing the fate of Adobe’s beloved flash video format. Ok so what does this mean to a real layman? Video support will be much more broad, no more third-party plug-in from another company to run video. Also devices such as the iPad will fully support it. Don’t fear you flash developers; Adobe will be around for quite some time, that is if they just adjust their strategy, sell their studio software, but support conversion to VP8 video format, as well as any other format that comes along.
Posted by Patrick at 9:05 PM 0 comments
Patrick Simpson has invited you to Dropbox
| ||||
| ||||
|
Posted by Patrick at 9:32 AM 0 comments
Wednesday, April 14, 2010
Firebug Demos
Posted by Patrick at 9:20 AM 0 comments
Labels: firebug, Firefox, web development
Thursday, January 21, 2010
Questions to start a project
I’ve started a list of questions to establish constraints for project work. These are targeted to web development (since that’s my area), but should be part of a larger series of questions that are asked when taking on a project. The idea is to discover the constraints the project runs under, and to force the issue on decisions that need to be made but have not. I’ll try to update these as they change.
Browsers
- Is there a specific set of browsers that must be supported? If not, then the [http://developer.yahoo.com/yui/articles/gbs/](YUI Graded Browser Support) will be used.
- If there are specifics, please specify for the following browsers. OSes tested on will be Windows XP and OS X 10.5+. Internet Explorer, Firefox, Safari, Chrome, and Opera.
Window size
- What is the smallest window size that must be supported? If not specified, then 800×600 will be used.
- What is the largest window size that will should tested against? If not specified, then 1440×900 will be used (size of the laptop I test on).
- Is there a preference for a fluid or fixed layout? If not specified, a fluid layout will be used. If a fluid layout is preferred, will mockups/images at multiple screen sizes be provided?
CSS
- Is the project already using a library for CSS, such as YUI Grids? If not, then http://developer.yahoo.com/yui/3/ Grids/Base/Reset/Fonts CSS files will be used. This will be accessed via a Content Distribution Network hosted by Yahoo or Google (in other words, the files will be served from an outside network to increase page speed and take advantage of caching).
- Is there any restriction against using conditional comments for various versions of Internet Explorer? If not, these will be used to target CSS and javascript fixes to versions of IE as needed.
- Is there any issue with progressively enhancing the website for advanced browsers? This means that certain effects such as rounded corners will NOT show on out of date browsers, such as IE6. If not, CSS3 techniques will be used to create effects such as rounded corners.
Javascript
- Is the project already using a library for javascript, such as jQuery, YUI, Blueprint, etc? If not, then either YUI or http://jquery.com/ will be used, usually the latest stable version available. Again, this will be accessed via a CDN where possible.
Working in a code base or on my own?
- Will I be working in the production code base or creating my own prototype?
Accessibility
- Are there any specific accessibility requirements? If not, then [http://www.w3.org/TR/WCAG20/](WCAG 2.0 “The latest a11y guidelines from the W3C”) and http://www.w3.org/WAI/intro/aria will be targeted/implemented in the code.
Agile, waterfall, other?
- Is there a specific methodology being used for the project that I will need to participate in, such as daily standups? What are the dates and times for those meetings, and what I am expected to contribute to those?
IDE/environment
- Is there a specific IDE or environment that must be used, such as .NET studio, Eclipse, etc? Is there a specific version control system that must be used? If not, I will use a text editor and our own vcs repository.
Server side Languages
- Is there a specific server side language that I must use? If not, PHP will be used.
Final deliverables
- I will deliver HTML, CSS and javascript, optimized for performance. This means the CSS and javascript will be minified. All of the above will be delivered as URLs on our server, generated from a Server Side Language such as PHP. Is this sufficient, or do I need to provide a zipped/tarred version of the files?
- Will I be helping to integrate the delivered items into the production code base?
Debugging
- Will I be expected/asked to help debug production code issues once a release has occurred?
Posted by Scott Plumlee at 11:05 AM 1 comments
Tuesday, October 27, 2009
JavaScript Plugin of the Month - jQuery mbTooltip
Posted by Patrick at 3:11 PM 0 comments
Friday, September 25, 2009
On doing it right the first time
Everyone who writes any sort of code has been asked to do a one-off - "just do it quick, it'll never be anything but a prototype". Even serious projects have this (see http://code.google.com/p/virtualagc/source/browse/trunk/Luminary099/LUNAR_LANDING_GUIDANCE_EQUATIONS.s?r=258, the comments for lines 179 and 180). The problem with this is that it's never just a one off. Every line of code we write gets used again and again because it's becomes easier to copy and paste something than to write it from scratch. If we don't do it right the first time, there's never time to go back. So how do we get the time to do it right? Simple. Don't give in on time estimates. When they say it's just a quick example, can't it be done in an hour or two, say no. Explain why you won't cheat the process. The only way we achieve the standards we want is to refuse to accept anything that doesn't meet those standards. Set a minimum bar and don't go below it. In the long run, it makes our work better, and makes us better teammates to those who depend on us. It may not be obvious at first, but the extra time we spend up front comes back to help out down the road.
Posted by Scott Plumlee at 4:40 PM 0 comments


