scott bellware [mvp]

scott bellware [mvp] sign in | join | help home blogs jobs photos downloads in scott bellware [mvp] (blog) codebetter.com blogs (group) (entire site) search scott bellware [mvp] the sure way to predict the future is to invent it ironruby in winforms the ruby in steel guys seem to be applying the knowledge of ruby and .net gained through building a ruby editor for visual studio and their ruby connector project to bring ironruby to winforms development. their latest screen cast is a demonstration of using ironruby to build a winforms app:http://www.sapphiresteel.com/static/movies/ironruby_formdesign1/ironruby_form_design_1.html i'm not a huge fan of the choices that they made for their ruby editor (ruby don't need no stinkin' .proj files), but the work that they're doing on interop as a result of their r&d for the editor is pretty exciting stuff. whether or not you like ruby in steel, the folks behind the project are out on the bleeding edge, demonstrating potential .net/ruby interop scenarios in working code, and their blog is one of the resources i have that helps me consider the potential of ruby and .net working in concert. the ruby in steel blog is at:http://www.sapphiresteel.com/-blog- here's hoping that jeremy miller will have some time over the end-of-year holidays to give it a spin and report back :) posted nov 12 2007, 12:03 pm by scottbellware with 5 comment(s) filed under: ruby community antipattern: gloryhound a gloryhound is a member of the community who seeks to better his position in the community by drawing attention to himself through networking, schmoozing, and glad-handing rather than through raw meritorious action. the work of a gloryhound leads to a degradation in the quality of guidance provided to the community as the gloryhound rarely tells the part of the story that displeases his benefactors rather than telling the whole story.  a gloryhound will trade honor for profit even when it hurts those he presumes to serve. a gloryhound's benefactors are commercial enterprises that gain by having their part of the story told, while obscuring parts of the story that point to the enterprise's weaknesses, or the weaknesses of their products. a benefactor will lend status to the gloryhound in exchange for the gloryhound's willingness to be complicit. gloryhounds gather around impending product releases, working with the benefactor to prop up the gloryhound as a recognized leader in the problem space that the problem addresses. we'll see this in the .net community around the release of the ado .net entity framework and even the asp .net mvc framework where people with relationships with microsoft will be put forward as leading practice guides for the product. entity framework gloryhounds will have little if any experience with or reputation in object-relational mapping and persistence, and will necessarily provide guidance directly from microsoft's playbook.  the gloryhound's willingness to be complicit will contribute to communicating and reinforcing poor software practices in the community, and the arbitrary reduction in the quality and success of projects and systems, as well as an unnecessary setback to the march toward quality. a gloryhound is easily identifiable by his sudden appearance as a practice leader around a new software product where no real trail of deep and substantial practice experience with the product's problem domain exists in the public record - either in his blog, his demonstrable work, or his teaching. gloryhounds are often already visible members of the community.  upon achieving a certain level of authority in their particular specialization, and a sufficient level of visibility, they rally to an impending new technology release, and work with the benefactor to bring a semblance of impartial evangelism to the community while the benefactor provides the gloryhound with opportunities that bolster his status through promotional engagements supporting the new technology. gloryhounds often use their personal networks to reinforce a perception of competence and experience through visible association with recognizable practice leaders.  they stand near real leaders and claim through that proximity the credibility of folks doing early path finding and the initial community development. gloryhounds are often sources of useful tidbits of inside information, but their guidance should be taken with a does of skepticism since their duplicity would permit them to steer their audience toward irresponsible and negligent practices if it suited the benefactor's agenda for evangelism, and the gloryhound's agenda for self-service. the way of the gloryhound is often a path to material success, and we're all susceptible to it.  a gloryhound's work in the community is often amounts to long-term a net-loss, and it's incumbent upon community leaders to constantly be checking their materialist drive against the greater good of the community's ability to learn and to sustainably better itself. acting as a visible member of the community put people squarely in the path of becoming gloryhounds.  it's a fine line to dance on.  community leaders who more often put the community's interests above their own may transgress, but immediately get back onto the line.  a gloryhound will actively seek to rid himself of the constraints imposed on his self-interests by staying the course and remaining true to that fine line. a gloryhound's guidance will often lead your practice down the garden path through the cumulative effects of half-truths and ignorance coupled with an authoritative voice.  you can avoid the inevitable pain of following false profits by watching the patterns from where they emerge. with every new technology widget, some visible community guy is looking to become the new, famous specialist.  look for new releases and new announcements, and amidst the gathering throng there'll be a gloryhound. at the intersection of technology releases and sycophantic predispositions, you'll find the guy who's grooming himself to be the next gloryhound.  if you can figure out who it is, you can save yourself and your projects some pain by being able to knowing to put his advice in context with his agenda. posted nov 12 2007, 02:27 am by scottbellware with 40 comment(s) filed under: commentary, community kevin nails windows live usability degredation http://blogs.dovetailsoftware.com/blogs/kmiller/archive/2007/11/08/is-the-software-installer.aspx posted nov 08 2007, 02:54 pm by scottbellware with no comments filed under: microsoft, usability in-browser ironruby in the next silverlight ctp from john lam: "once we (dlr) sync up with the next ctp of silverlight, you'll be able to run ironruby in your browser" source: http://www.iunknown.com/2007/11/ironruby-on-sil.html posted nov 05 2007, 05:25 pm by scottbellware with no comments filed under: microsoft, ruby silverlight 1.1 as a browser test automation foundation? just thinking out loud (probably a thought that tons of people have already had). tools like watir, firewatir, safariwaitr, and watin are all separate implementations of a web ui testing tool pattern explored originally by watir and made popular because of its viability and usefulness. we're challenged as web development teams because we need to use a different tool to test an app on different browsers: watir for ie, firewatir for firefox, safariwatir for safari, and watin for ie for people with incurable cases of rubyphobia. we would benefit from a universal browser plugin that has a single api that gives harmonious access to the browser's dom.  theoretically, instead of using three browser test automation tools, we'd use one.  we might be able to get away with expressing tests once and targeting different browsers at run-time. is this what silverlight might do for web testing? p.s.  if ironruby does come to fruition, rubyists would be covered as well... again, theoretically. posted nov 05 2007, 09:41 am by scottbellware with 8 comment(s) filed under: ruby, testing, tools show your spaces here's what's in mine: posted oct 30 2007, 03:52 pm by scottbellware with 18 comment(s) filed under: mac bret on stories and bugs when is a bug a story?http://www.io.com/~wazmo/blog/archives/2007_10.html#000262 posted oct 29 2007, 07:59 pm by scottbellware with no comments filed under: agile, testing the problem with writing acceptance tests in a custom dsl writing acceptance tests in a custom testing dsl is a chicken-and-egg problem and a problem of distraction-by-untimely-maintenance. i didn't like my experience with fitnesse because it seemed to demand so damned much time from the programmers. the care and feeding of a fitnesse suite came to outweigh the benefits of using it. the same problems that fitnesse has might might pop up in rbehave as well. in fitnesse, you write fixture classes to interpret between the tests written in the wiki in fitnesse's special wiki-ish external dsl. in rbehave, you write matchers that turn plain-old english into test executions. this is an actual test in an upcoming release of rbehave: story: simple addition as an accountant i want to add numbers so that i can count beans scenario: add one plus one given an addend of 1 and an addend of 1 when the addends are added then the sum should be 2 and the corks should be popped you would write matchers that look for specific keywords and generate the executable parts of the test at runtime. checkout david chelimsky's post on plain text stories for more: http://blog.davidchelimsky.net/articles/2007/10/25/plain-text-stories-part-iiithis approach, which is similar in spirit to fitnesse, is great when you are working with a domain that is pretty well-known, and an application class model that has pretty much already been fleshed out over some period of time. the problem with fitnesse was the maintenance of the language interpreters during the period when the language was still up in the air - which is pretty much the entire time that the project is under development. the chicken and egg problem in fitnesse and rbehave, you write language interpreters. these interpreters are ultimately the implementation classes for a custom dsl over your application's domain implementation classes. so, we're writing the dsl while we're fleshing out the apps' domain and it's domain classes. any change in our understanding of the domain and its language has to be reflected in the fitnesse or rbehave tests - the interpreters and the tests themselves. we're essentially maintaining a dsl over a domain that often isn't semantically or syntactically stable in a practical sense yet. the maintenance problem as we gain new understandings of the content and geometry of the domain, we change the domain implementation classes. any change to the domain means making changes to the natural language resources that use the interpreters that sit on top of the domain, as well the interpreters themselves. since acceptance tests explore many more test cases than developer tests, there's a lot of changes to make. here's the kicker: you also write unit tests against the language interpreters for your custom testing dsl. changes to the domain means test-driving those changes and then test-driving the interpreters. if you're working on applications that explore new implementations of a model, or that explore entirely new models, following custom dsl-based acceptance testing practices could seriously increase the friction that your team would experience in the process. an alternative we use fitnesse and rbehave to increase the visibility of acceptance tests and acceptance testing to folks on the edge of the technical team. the intention is to bring customers into the acceptance testing loop. we give them natural language-oriented tooling so that they can oversee the tests and the testing, and even contribute to the effort by writing tests using the custom dsl. in order to pull this off, we often saddle the technical team with some non-trivial friction. bringing non-programmers on-line to create system tests is a bit of an above-the-call-of-duty assignment for a team that is already tasked with solving a line-of-business application development problem. i think stock rspec or even low-fi bdd with an existing unit testing tool and some naming conventions can go a long way to solving the customer visibility problems without having to maintain the extra stuff that allows us to write tests in natural language. if you've got a way to export the your specifications (as you do with rspec, and as i do with a custom utility for nunit), you can rely more on your relationship and communication with the customer to close the gap that fitnesse and rbehave are attempting to close with technical solutions. getting natural language specs into your customers hands and incrementally and continuously reviewing the specs with the customer, as well as releasing working software often, will go a long way to solving many of the problems that fitnesse and rbehave are aimed at. dismount i thoroughly understand the value of customer-visibility in application verification, but it appears to me that the drive for natural language testing languages is something that programmers are often a lot more excited about than the customers that these tools are supposed to serve. i'm not violently opposed to the tools and approaches supporting customer acceptance testing, but i'm very doubtful of the present state of the art, and i'm suspicious of the faint smells of technology fetishism that seems to surround the teams - including me and mine - that indulge it. just a little closing thought to chew on... why are we asking customers to get into the testing effort? don't they have enough to do already? shouldn't they be able to work through the natural agile process and still come out on the other side with working software forged by competent programmers, designers, and analysts as enabled by solid relationships built on trust and accountability? posted oct 28 2007, 10:16 pm by scottbellware with 13 comment(s) filed under: agile, behavior-driven design, ruby, test-driven development, testing opening outlook ics in mac ical i got an email this evening with an calendar attachment for a conference call scheduled to take place using microsoft's livemeeting. opening the ics file would open the mac ical app, but wouldn't import the event.  i opened up the file in a text editor and compared the contents to what i found on the apple's developer site for ical as well as the ietf's page covering the icalendar spec. in the spec, the mention of the method element (near the top of the file) describes this element as optional, but also refers to it in lowercase.  in the outlook-oriented ics attachment from livemeeting, the method element is allcaps. i changed method:request to method:request and ical was able to import the event. posted oct 27 2007, 01:57 am by scottbellware with 5 comment(s) filed under: mac, microsoft, tools why can't windows live mail do pop3 or imap? i just upgraded my macbook pro to os x leopard.  go figure... the only thing that didn't work after the upgrade was the mail plug-in that acts as a demystifier for hotmail. i used to think that enabling hotmail with pop3 or imap was a purely technical challenge, but with other web mail providers having long ago shown that it can be readily done, i'm not so willing to believe that the issue is technical at all. the idea of shutting down my hotmail account is really daunting.  i've had it for many, many years and it's an identity that is used for a good number of resources in my digital life.  but the frustration of dealing with the usability clusterfuck that stems from the windows live organization's unwillingness to address the protocol compliance of their mail service is becoming so egregious that shutting down that account is starting to look attractive - regardless of all the effort that it will take on my part. "trapped" is such a common microsoft service experience.  it's always about the lock-in for them.  user experience so readily takes a back seat in the microsoft sphere when a potential for a cross-sell or an enforced loyalty comes into play. other services have raised the user experience expectation bar way above where hotmail dares to go.  my expectations for good service and good experience have been forever skewed by more customer-centric providers.  i truly regret having invested trust in hotmail all those years ago.  had i not been one of the unwitting faithful so long ago, i wouldn't feel so trapped now. my gmail acount is free.  my hotmail account comes with an annual fee.  i can't even pay microsoft to render good service. posted oct 26 2007, 10:47 pm by scottbellware with 16 comment(s) filed under: commentary, microsoft alt.net - what it means to me lot's of good conversation lately about what alt.net means to folks.  here's what it is for me: alt.net => :values => [:diversity, :integrity, :courage] posted oct 23 2007, 03:59 pm by scottbellware with 5 comment(s) filed under: community user stories brain dump as a call center triage agent, i want send a customer's request for support to the right support queue so that a group of helpdesk workers with the right knowledge can render the level of service appropriate to the customer and the customer's service contract.     user stories are generators for other artifacts generated on the project and efforts undertaken by the project team. tests, code, documentation, ui mockups, schedules... all have roots in the beginnings and understandings forged by user stories.     user stories are the primary unit of project management.  estimates and measurements of effort are assessed against user stories.  schedules and plans are made in terms of stories.  progress can be observed as user stories march across the story wall from backlog to done.     user stories are written from the perspective of a user role.  the old "as a user, i want..." should be avoided.  sometimes it's hard to come up with the nouns that describe the user role, at which point you might need to fall back on "as a user concerned with <some observable piece of business value>..."  work extra-hard to think your way out of these jams and surface the actual user role.     a story's user role often matches up to a job title in the organization, but that could be a coincidence more than a rule.  tease out the user roles.  if they match up to job titles in your organization, you can decide to use the titles if doing so benefits the team and the project.     a user story should capture the user's goal and motivation.  this helps bring focus to the team's efforts to surface user experiences and software modules that more closely map to user's needs.  this improves the acceptability of the software and reduces waste.     user stories provide a context for creating and capturing acceptance criteria.  some high-level acceptance criteria should be captured right on the story card (often on the back of the card).  the surfacing of first order acceptance criteria marks the beginning of specification and design of the software that will serve the story.     user stories, via acceptance criteria, are the starting point for test-driven development, or more precisely, for bdd-styled specification.     a user story isn't an object model. it should not be mechanically decomposed into nouns and verbs.  definition of the object model results from specification of the behaviors thorugh bdd and tdd practices.     user stories are transmitters and hosts of the project domain's shared language.  the shared language is surfaced in user stories and story-writing sessions.  the language continues to be refined through the project as new knowledge about the domain is surfaced and as more precise understandings are discovered.     user stories are shared artifacts.  they are owned by the whole team, including project owners, customers, developers, testers, technical writers, and any other roles you have that gets you to shipping software.  no one functional group should assume ownership of stories.  stories impact everyone's work.  it's all too easy to mistakenly come to believe that stories are more important to your own work that to others.  practice awareness, and work to avoid this conclusion and the detrimental effects to the project and the team that come from it.     only one version of a user story should exist.  creating multiple copies of a user story will cause them to go out of sync, leading to divergent understandings of the user's needs and the solution that the team responds with.  if one functional group makes a copy, it's their responsibility to keep their copy in sync, and they have no ability to place restrictions on changing, splitting, or disposing of the master copy.     a story is a place-holder for a conversation.  it is deliberately terse and incomplete.  a developer must have on-going communication with a product owner and the team in order to get enough information about the story to do the technical implementation work.  the team will continue to converse about the story as it's brought to fruition.  the conversations will surface ambiguities and mitigate them, and will strengthen the team's sense of shared value of the story and the vision of the software that serves the story.     a user story should be brought through the development cycle by a single team housed in a single location.  much of the communication that gets a story to "done" happens through osmotic means.  if a story moves into another location to be served by another team, for example, an offshore testing group, then much of the story's meaning won't go with it - even if we endeavor to "write it all down".     user stories should be housed on the most accessible and visible information radiator possible, and using media that is the most neutral to the various usability predispositions of all the roles on the project to whom the stories belong.     user stories should fit on an index card.  if you've written more than will fit on an index card, you might consider splitting the story into multiple stories, or refining the language used to tell the story.     a user story should be captured on an index card, or other tangible, transportable medium.  we don't use index cards because we're too lazy to implement an electronic solution.  we use cards because we use the stories in variety of contexts that are still most effectively served by a piece of physically tangible and transportable material.  we spread an iteration's worth of stories on a table top and negotiate their meaning; we hold them in our hands and look at them while developing a vision for the problem and the solution; we write a variety of datums on them in unstructured ways; we pass them around the table when throwing estimates with the team; we bring them to our desks for a moment, and then pin them back on the wall; we readily change their status by moving them into different physical queues on the story wall.     user stories are for the core team, not ancillary observers.  the fluidity of user stories should never be made rigid by concerns such as status report up the chain of command.  if an upper level stakeholder wants status reporting, the project mediator should allow for time in his schedule to produce those reports, and not force cards into an electronic database just to facilitate the fulfillment of his reporting responsibilities.  if outside observers require line-level access to the progress, they should be invited into the team room, or be encouraged to take a hike lest the team's effectiveness be affected detrimentally by ancillary concerns, information fetishes, and micro-managers.     user stories are finite and disposable.  we throw them away when we're done implementing them (or we put them in show box with the intention of returning to them, and rarely, if ever, do).  we're after software that has been shipped and accepted by the customer.  once we have software in hand, the focus of the conversation shifts to the software and its acceptance criteria.  what was once acceptance criteria for a story transcends the story and remains as acceptance criteria for the software.  stories dissolve into the passing of time as the customer's attention shifts increasingly toward the software they need to get their jobs done.  if multiple copies of a user story exist, all copies of the story should be taken out of active service simultaneously.     stories aren't mechanisms for assessing blame.  if the software is ever wrong, arguing over the interpretation of the story is irrelevant and counter productive.  we move forward with new acceptance criteria and new estimates and we work in concert with the customer to get it right.  we don't resurrect stories that have already been accepted to account for new information or requirements, we write new stories that reflect new or clearer requirements and move on. posted oct 22 2007, 02:46 am by scottbellware with 7 comment(s) filed under: agile, behavior-driven design the difference between a technology evangelist and a technology guru a guru will wait patiently for you to come to him.  he will let you make your mistakes knowing that the mistakes will inform your learning when you finally decide that learning what he has to teach is important to you.  he will let you go when you become disillusioned and welcome you back without recrimination. an evangelist will come to your house, forcing you to experience the embarrassment of telling him to go away, and bank on your sense of propriety that you will not confront him about cheapening his beliefs by peddling them door-to-door like some morally-devolved brush salesman.  if you don't give him the "i'm not interested" line, he'll shove his one-dimensional wares down your throat until there's no more room in your lungs but enough to repeat the name of his brand. if only evangelists were savvy enough to realize that we are often more put off by evangelism than by the message.  this is what a guru knows, and he knows to protect the fragile space where learning happens from the distraction of head-counting and metrics-chasing. you'll know a guru by his willingness to scare you off, and the evangelist by his motivation to keep you hooked. posted oct 21 2007, 10:45 pm by scottbellware with 16 comment(s) filed under: commentary, community neal ford points to a possible future for developer testing on .net since the dlr and ironruby were announced, we've been talking about a possible future when developer testing and specification tools like rspec might be used for .net projects. simpler approaches to using mock objects are part of the world-of-wonderment in an age of ironruby. if we're able to mock in .net the way that we can in ruby, then we end up with more soluble, intention-oriented, and expressive test code and application code for those parts of our systems that benefit from a focus on language-oriented programming values. neal ford talks about taking advantage of mocking in jruby:http://memeagora.blogspot.com/2007/10/mocking-jruby.html this may also be a possibility for .net developers at some point in the not-so-distant future. posted oct 21 2007, 12:28 pm by scottbellware with 9 comment(s) filed under: ruby, test-driven development i do bdd because... ...it helps close the gap between business people and technology people. ...it helps surface and maintain a shared language that describes both the business value and the application....i serve the flying spaghetti monster. bdd is like tdd with business tentacles, reaching out through programmers and into customers, making for more shared understanding as its noodly appendage touches more people. ...it makes user centric design more accessible. the need for user context is tuning us to write better user stories and think more about what the user is doing with the outer hull of the classes and modules that we're writing. context-driven analysis immerses us in the raw materials for the shared language that gives the specs their conceptual contours. ...it helps close the gap between qa testing and developer testing. unit tests are acceptance tests at a different level of detail; the test continuum is smoother. acceptance criteria fuel the transition from story card to code. ...it makes my estimates better. practicing unit tests as a form of acceptances tests helps me shift my thinking down the continuum from ui needs down into the model code when i'm throwing an estimate. i seem to be generally aware of more factors about the domain, the users, and the functionality that has already been filled-in. ...it puts an onus on the product owner to think through their needs a bit more. we like acceptance criteria. story writing, planning, and the basic geometry of the system are fueled by acceptance criteria. capturing some acceptance criteria while capturing the story and an estimate with the product owner gives him a context to talk through a bit more of his vision, and this guides us on a truer trajectory....my code is becoming clearer. i'm much more attuned to solubility because deviations from it are more readily apparent in the language.   posted oct 19 2007, 04:03 am by scottbellware with 6 comment(s) filed under: behavior-driven design more posts next page » this blog home contact syndication rss atom comments rss recent posts ironruby in winforms community antipattern: gloryhound kevin nails windows live usability degredation in-browser ironruby in the next silverlight ctp silverlight 1.1 as a browser test automation foundation? tags agile analysis behavior-driven design behavior-driven development boo books c# comic commentary community data access design devteach domain-driven design dovetail dynamic entity framework events eventual app featured featured: agile humor mac microsoft nhibernate object-relational mapping open source overheard product design revent ruby ruby and rails satire solubility test-driven development testing tip tools usability water web windows archives november 2007 (5) october 2007 (26) september 2007 (41) august 2007 (16) july 2007 (24) june 2007 (19) may 2007 (5) april 2007 (30) march 2007 (12) february 2007 (1) january 2007 (3) december 2006 (17) november 2006 (7) october 2006 (8) september 2006 (19) august 2006 (11) july 2006 (2) may 2006 (3) april 2006 (2) february 2006 (3) january 2006 (7) december 2005 (6) november 2005 (6) blogads google jobs.codebetter.com about codebetter.comcodebetter.com faqour manifesto subscribe google reader or homepage del.icio.us codebetter.com latest itemsadd to my yahoo! subscribe with bloglines subscribe in newsgator online subscribe with myfeedster add to my aol furl codebetter.com latest items subscribe in rojo member projects wsmq - brendan tompkins sarasota web design - david hayden dotmath - steve hebert ezweb - jeffrey palermo structure map - jeremy d. miller storyteller - jeremy d. miller the code wiki - karl seguin  friends of codebetter.com red-gate tools for sql and .net blogjet codesmith 3.0 sourcegear vault telerik componentart vistadb jetbrains - resharper beyond compare .net memory profilerndepend <-- new friend! site copyright © 2007 codebetter.com content copyright individual bloggers

Acceuil

suivante

scott bellware [mvp]   K. Scott Allen  Venise 2007 : Ridley Scott présente "Blade Runner : Final cut ...  Frères Scott (Les) - photos  Scott Bakula Ados.fr  The Story of Feedster  Scott micro-chaine dvd/mpeg4 usb mdx 35 grossiste importateur ...  LES FRERES SCOTT (saison 4 DVD 6/6), le film en DVD  skippy dot net  Les Freres Scott One Tree Hill Media Photos TF1 Plug TV The WB - Home  Acheter Autoradio SCOTT DRXi800T, prix  Ridley Scott, Acteur  Official site of Darrell Scott lyrics, tickets, bio, pictures ...  Scott McNealy - Bio  SCOTT MICRO-CHAÎNE DVD/MPEG4 USB MDX 35 acheter comparer prix ...  Dr. Scott Fairgrieve p...  Sport24 - Tennis : Scott : «On n'a rien reçu»  Sport24 - Golf : Scott Strange en tête  - Air Liquide: acquisition de Scott Specialty Gases aux USA ...  S. S. Trudeau  Oeuvres de Walter Scott - Résultats Google Recherche de Livres  Scott Vaughan  Gimp-fr documents effet Ron Scott  Jill Scott : plus qu’une artiste, une voix d’or  Les Frères Scott saison 1 en DVD  Scott RDX25S - Minis chaînes (Chaîne Hi-Fi) - Chaînes Hi-Fi Neuves ...  Scott : Tout sur Scott - Moto & Scooter - Caradisiac Moto  Les Frères Scott - Le Blog - AlloCiné Blogs  Les Frères Scott - Le Blog - AlloCiné Blogs  Vidéo "Les frères Scott 4x21 FR 2/3" de oth5910 (Séries > Séries ...  Vidéo "Les frères Scott 4x21 FR 1/3" de oth5910 (Séries > Séries ...  Blankbaby: The digital home of Scott McNulty  Scott Mitchell  Air Liquide : a conclu l'acquisition de Scott Specialty Gases ...  Piratage : Ridley Scott critique la technologie - PC INpact  Scott DX575 VCS - Comparez les prix - PC INpact  Scott Buffett Personnel ITI-CNRC  William Scott Personnel ITI-CNRC  Ridley Scott - Fluctuat.net  Tony Scott - Fluctuat.net  Montgomery Scott - Memory Alpha  Les Îles Scott - Profil des îles Scott  Welcome  musique-chroniques.ch > Scott-Heron, Gil  Le blog de scott.mckay Parti vert du Québec  YouTube - Gil Scott-Heron -The Bottle  Carson, Pirie, Scott and Company Store - UNESCO World Heritage Centre  Jill Scott Accueil Artiste sur Yahoo! Music  Dangerously Irrelevant  Scott Instruments - gas detection for airborne hazards  Ridley Scott, les films de Ridley Scott  Francis Scott Fitzgerald - Fluctuat.net  Visual Studio Talk Show:0054:Scott Bellware:Ruby on Rails et l ...  Assemblée législative de l'Ontario Députés Députés actuels ...  Robert Falcon Scott - Wikipedia, la enciclopedia libre  Albums cultes des géants du bizarre #18 : Scott Walker – Tilt  Official RAYMOND SCOTT site Composer & Inventor Raymond Scott (b ...  thescott — just another blog. written by scott gray.  James Scott : Domination and the arts of resistance : hidden ...  Scott Autoradio DVD MP3 DRX-i800  HELLO, my name is BLOG!