Breve Historia do SharePoint (A perspectiva dun parente recén chegado)

Nota: Este artigo foi orixinalmente publicado o www.endusersharepoint.com. I forgot to post it to my own blog 🙂

SharePoint evolucionou moito desde os seus primeiros días como unha especie de tecnoloxía de incubación Microsoft –el evolucionou case como unha película de terror, onde a creación do científico tolo asume unha vida propia, breaking free of its creator’s expectations and rules. The technical evolution is obvious – the WSS 3.0 modelo de obxecto é máis rico e complexo que WSS 2.0, which was itself an improvement over earlier versions. The next version will no doubt show tremendous improvement over 3.0. From an End User’s perspective, con todo, Evolución do SharePoint é aínda máis significativo.

Os primeiros días, SharePoint didn’t offer much to End Users. They would have their usual functionality requirements, work with IT to define them well and implement a solution. IT would use SharePoint to solve the problem. The product wasn’t very accessible to End Users. I’ve thought threw a few analogies, but I decided to stick Venn Diagrams to show what I mean. When Microsoft first released SharePoint to the world as a commercial offering, seguiu un patrón concepto tradicional de Usuario Final <-> IT relationship. A lot of End Users, comunicar e traballar con un número moi pequeno de persoas de TI para ofrecer solucións que resolvan problemas de negocios:

O dominio global de problema para o cal o SharePoint é unha plataforma de entrega axeitado é pequena (especially compared to today’s SharePoint. End Users and IT worked in a more classic arrangement with IT: establecer os requisitos de TI, esperar a TI facer o seu traballo por tras da cortina e aceptar a entrega do produto final.

Como SharePoint evolucionaron ao 2.0 mundo (WSS 2.0 e SharePoint Portal Server), several things happened. Primeiro, the “problem domain” increased in size. By problem domain, I mean the kinds of business problems for which SharePoint could be a viable solution. Por exemplo, non vai pensar moito sobre a implantación dunha solución de busca serio nun ambiente SharePoint ata SPS (e aínda así, que non era tan bo que el precisaba ser). Á vez, Os usuarios finais teñen unha capacidade sen precedentes, non só para definir, but also implement their own solutions with little or no IT support.

O 3.0 plataforma (WSS e Moss) maintained and increased that momentum. The problem domain is enormous as compared to the 2.0 plataforma. Virtually every department in a company, que van dende a saúde de fabricación e os departamentos de seguridade para o marketing, de vendas para control de calidade - poden atopar un bo uso para SharePoint (e non é un caso de usar un cravo redondo nun burato cadrado). Á vez, the platform empowers even more End Users to implement their own business solutions. I try to capture that with this diagram:

This has proven to be both a potent and frustrating mixture. O 3.0 platform turns previously stable roles on their heads. Suddenly, Usuarios finais son efectivamente xuíz, xurado e verdugo Analista de Negocios, application architect and developer for their own business solutions. This gets to the heart of the problem I’m writing about. But before I dive into that, imos considerar o elefante na sala.

Perscrutando a Bóla de Cristal

Como será SharePoint 2010 afectar este estándar? Will it be incremental or revolutionary? Will more, ou menos o mesmo número de usuarios finais atópanse a habilitados a construír solucións en SharePoint 2010? Will SharePoint 2010’s problem domain expand even further or will it just refine and streamline what it already offers in WSS 3.0 / Moss?

Non hai información suficiente "aí fóra" para dicir con seguridade que a resposta xeral é:

• The problem domain is going to dramatically expand.
• Usuarios Finais van atopar-se aínda máis poder do que antes.

The Venn Diagram would be larger than this page and cause some IT Pros and CxO’s to reach for their Pepto.

I believe it’s going to be a tremendous opportunity for companies to do some truly transformational things.

Non Bulls en My China Tenda!

Isto soa moi ben, pero desde o meu punto de vista como consultor SharePoint e poñendo-me na pel dun director de TI, I see this vision. I own a China shop with beautiful plates, cristal, etc (meu ambiente SharePoint). I’ve rented a space, I’ve purchased my inventory and laid it all out the way I like it. I’m not quite ready to open, pero en anticipación, I look at the door to see if my customers are lining up and I notice an actual bull out there. I look more closely and I actually see dous bulls and even a wolf. Then I notice that there are some sheep. Sheep are así malo, pero son eles quizais disfrazado lobos? I don’t want bulls in my china shop!

Queda peor! When I rented the space, I couldn’t believe how nice it was. Wide and open, excelentes amenidades, very reasonable price. Con todo, agora estou entendendo que os espazos abertos ea enorme porta é perfectamente dimensionado para un touro para vir vagando e lanzar residuos para a miña china.

Estou empurrando esta analoxía lonxe demais, claro. End Users are not bulls (a maioría deles, de calquera xeito) e os departamentos de TI non (ou por suposto non debe) view their user community with that kind of suspicion. Con todo, non existe ese tipo de colisión perfecta produciron xa no o 3.0 platform that I expect will only get worse in SP 2010. SharePoint already empowers and encourages End Users to define and implement their own solutions.

Isto é óptimo e todos, pero o certo é que aínda é un produto moi técnico e aínda apela ao tipo de análise de requirimentos de negocio vigoroso, design and general planning and management that technical projects require to be successful. These are not the kind of skills that a lot of End Users have in their bag of tricks, especially when the focus is on a technical product like SharePoint.

I’ve given this a lot of thought over the last year or so and I don’t see any easy answer. It really boils down to education and training. I think that SP 2010 vai cambiar o xogo un pouco e que vai xogar de forma diferente e en cámara lenta como as empresas lanzar o seu SP 2010 solucións máis 2010 and beyond. In order to succeed, End Users will need to transform themselves and get a little IT religion. They’ll need to learn a little bit about proper requirements
analysis. They will need some design documentation that clearly identifies business process workflow, for instance. They need to understand fundamental concepts like CRUD (crear, actualizar e borrar), dev / test / qa / prod ambientes e como utilizar esta infraestrutura para aplicar correctamente solucións que viven un bo tempo e dobrar (non romper) en resposta a cambios na organización.

Nas próximas semanas, Eu pretendo tratar proporcionar algunhas das miñas propias ideas novas, así como enlace ao gran traballo feito por moitos outros autores (en www.endusersharepoint.com e noutras partes) so that interested End Users can learn that old time IT religion. Keep tuned.

</final>

Rexístrate para o meu blog.

Siga-me no Twitter http://www.twitter.com/pagalvin

[Nota: Este artigo cross-lanzado Usuario final SharePoint aquí: http://www.endusersharepoint.com/2009/09/09/sharepoint-a-case-study-in-ask-the-expert/]

Ás veces, cando se está a traballar como consultor (como unha profesión, ou nun papel consultivo na súa empresa), you find yourself living in an Onion story. The Onion has a series of articles called “Ask an [especialista] sobre [problemas]". This follows the famous “Dear Abby” format where a concerned person is asking for personal advice. The onion’s “expert”, con todo, is so focused on his/her area of expertise and current problems that the expert ignores the question entirely and rambles on about his area of expertise. As consultants, we need to keep that in mind all the time and avoid falling into that trap. It’s classically described like this – “when you use a hammer all day long to solve your problems, everything starts to look like a nail.” We professional consultants are always on guard against that kind of thing, pero entramos en contacto con persoas que son profesionais serios no seu propio papel, but are not consultants. They don’t have the same need or training to do otherwise.

Semana pasada, Eu escribín sobre un dos clientes da miña empresa e un proxecto en curso we have to enable high quality collaboration between various eye doctors in the US and Canada performing clinical research on rare disease. In addition to leveraging core SharePoint features to enable that collaboration, we’re also working an expense submission and approval process. It’s complicated because we have so many actors:

• Un puñado de individuos en consultorios médicos distintos dos que poden entrar na liña de gastos.
  • Hai máis de 40 consultorios médicos.
  • Nalgunhas prácticas, o médico usa o sistema directamente.
  • En moitas prácticas, persoal do médico usa o sistema directamente.
• Un administrador financeiro (que traballa para o meu cliente directo) que analiza os gastos para a precisión e relevancia, aprobar ou denegar-lles a nivel de organización.
• A 3rd party accounts payable group. These people pay all of the bills for out client, not just bills coming out of the rare disease study.

The Accounts Payable group has been a challenge. Working with them yesterday reminded me of the Onion series. In my role as business consultant, Expliquei a necesidade de que a empresa contas a pagar:

• Clínicas locais de estudos (consultorios médicos) incorrer en gastos relacionados coa estudo.
• They log onto the “web site” and enter their expenses using an online form. Neste caso, the “web site” is hosted with SharePoint and the expenses are entered into an InfoPath form. Expense receipts are scanned, cargado e conectado directamente ao formulario.
• Un proceso de fluxo de traballo automatizado busca a aprobación do administrador financeiro axeitado.
• Vostede, dear 3rd party AP company – please review and approve or deny this expense. I’ll send it to you any way that you want (razoable).Neste punto na discusión, I don’t really care how it needs to be bundled. I want to work with the AP group to understand what they need and want.

Cando expliquei a necesidade, a 3 ª parte foi un mergullo profundo no seu argot mumbo Jumbo interno sobre os procesos de aprobación de gastos, A Oracle códigos, sinaturas vicepresidencia, 90 día turn-around, etc. And panic. I shouldn’t forget about the panic. One of the bed rock requirements of the consulting profession is to learn how to communicate with people like that who are themselves not trained or necessarily feel a need to do the same. Among other things, it’s one of the best parts of being a consultant. You get to enter a world populated with business people with completely different perspectives. I imagine it’s a little bit like entering the mind of a serial killer, excepto que non está arruinado a vida tras a experiencia (though entering the mind of an AP manager isn’t a walk in the park 🙂 [ver nota importante abaixo ***] ).

One of the great things about our technical world as SharePoint people is that we have ready-made answers to many of the very valid concerns that people such as my AP contact have. Is it secure? How do I know that the expense was properly vetted? Can I, como o pagador finais de, ver todos os detalles do gasto? How do I do that? What if I look at those details and don’t approve of them? Can I reject them? What happens if the organization changes and the original approver is no longer around? Can we easily change the process to reflect changes in the system? Podo revisar esa gasto, un ano despois, e cando eu fico auditivas e precisa defender o pago?

Como a xente do SharePoint, we can see how to answer those questions. In my client’s case, nós respostas las máis ou menos así:

• Forma de InfoPath para permitir que sitios para rexistrar os seus gastos e sometelos a aprobación.
• Sitios poden volver ao sitio web para ver o estado do seu informe de gastos, en calquera momento.
• Como ocorren eventos significativos (e.g. o gasto é aprobado e presentado para pago), o sistema de forma Proativo notificaralle-los por correo-e.
• O sistema notificaralle o administrador financeiro, xa un informe foi sometido á aprobación.
• Administrador financeiro aproba ou nega a solicitude.
• Tras a aprobación, o gasto é enrolado en un correo-e e enviado para a organización 3rd Party payer.
• O pagador parte 3 ten toda a información que precisan revisar o gasto e pode acceder ao ambiente do SharePoint para cavar os detalles (principalmente auditar o histórico para comprobar a "verdade" dos gastos).
• 3rd party payer can approve or reject the payment using their own internal process. They record that outcome back in the SharePoint site (que desencadea unha notificación de correo-e para as persoas axeitadas).
• No futuro, sería bo para cortar ese proceso de correo-e tranquilamente e, no canto alimentar a información de gastos directamente ao sistema.

En conclusión, hai un estilo de vida aquí que eu describir o punto do axente profesional de vista, but which applies almost equally to full time employees in a BA and/or power user role. Work patiently with the experts in your company and extract the core business requirements as best you can. With a deep understanding of SharePoint features and functions to draw upon, máis veces que non, será capaz de responder a problemas e ofrecer formas de mellorar o día de traballo, aproveitando recursos básicos do SharePoint.

***Importante: I really don’t mean to compare AP people to serial killers. Con todo, I could probably name some AP pro’s who have probably wished they could get a restraining order against me stalking them and asking over and over again. “Where’s my check?” “Where’s my check?” “Where’s my check?"

</final>

Rexístrate para o meu blog.

Siga-me no Twitter http://www.twitter.com/pagalvin

[Nota: este post é publicado na web atravesar Mark Miller aquí: http://www.endusersharepoint.com/?p = 1897]

Un dos da miña empresa clientes máis incomuns é un médico de Nova York, que é líder no seu campo particular da medicina (coidado dos ollos). Like many doctors, he has a strong interest in research. He wanted to do some research on a rare eye disorder that affects a relatively small number of people in the U.S. and Canada. I don’t know the number, but it’s really too small for a large pharmaceutical company to invest its own private funds with an eye toward eventual commercial success. I’m sure large pharma’s do some amount of research into rare diseases, pero creo que o U.S. government is probably the largest source of funding. Como calquera cousa, resources are scarce. Many doctors across the country want to perform research and trials. Como resultado, there’s more than a little competition for that government funding. This is where my company and SharePoint enter the picture.

The fundamental idea is that a master organization will recruit other doctors across the country and enlist those doctors’ practices in a particular research study. These individual practices must sign up with the master organization and then, posteriormente, sign up for a particular study. The relationships look like this:

• Unha organización mestre.
• Prácticas médicas distintas de moitos rexistrar coa organización mestre.
• The master organization obtains funding for individual studies. At the outset, hai só un estudo a un de unha enfermidade ocular rara, aínda específica xa estamos incrementando a outro estudo.
• Individual doctors’ practices sign up for specific studies. A specific practice could sign up for one or multiple studies.

A organización mestre en si está dividido en grupos:

• Comité Executivo
• Comité Director
• Individuais comisións de estudo
• Administración
• outros

Finalmente, cando a práctica dun médico específico rexistrarte para participar nun estudo, precisan para facilitar aos profesionais para atender a unha variedade de papeis:

• Investigadores (incluíndo un investigador principal, normalmente un médico, xunto con un ou máis investigadores adicionais)
• Coordinadores
• Técnicos
• Subvencións administradores
• outros

The above roles have very specific and highly proscribed roles that vary by study. I won’t get into more detail here, pero se vostede está interesado, deixar un comentario ou enviar correo-e me.

E agora podo responder á pregunta, SharePoint - O que é bo para? The answer – it’s really good for this scenario.

Esta introdución é xa máis do que eu esperaba, entón eu vou resumir o papel fundamental que o SharePoint desempeña na solución e mergullo en detalles nun artigo futuro (se non pode esperar, enviar correo-e me ou deixe un comentario e eu ficarei feliz en discutir e se cadra ata tentar facer unha demo). We are leveraging a wide array of SharePoint features to support this concept:

• Sitios para as comisións, papeis individuais (sitios de coordinador, centros de investigación, etc).
• Seguridade para asegurarse de que diferentes prácticas non ver os datos de outras prácticas de.
• InfoPath forms services for online form entry. This is a particularly big win. Normalmente, estas formas difíciles son impresos, enviado as prácticas, filled out and mailed back. The advantages to the online forms are obvious. They do introduce some complexities (licenzas e humanos) pero iso é outra historia.
• Fóra das partes da web cadro, como anuncios (cando fai comité [x] atopar?) e coñecer os espazos de traballo.
• Formas de identificación baseada en combinación con unha ferramenta CodePlex para proporcionar auto-rexistro e contrasinal esquecer características.
• Listas personalizadas e exhibicións de lista para a visibilidade en actividades de estudo que simplemente non son posibles con puro papel e lapis enfoques.

Con excepción do módulo de autenticación baseada en formularios e un puñado de formularios do InfoPath, este proxecto está utilizando case todos fóra da funcionalidade do SharePoint caixa.

Antes de concluír este estudo min caso, Quero salientar algo moi importante - non en parte con este proxecto (ademais da miña empresa de curso) has any idea that a thing called “SharePoint” is playing such a fundamental technical role. Nearly all of my end users view this as “the web site.” Our client values us because we’re solving their business problem. SharePoint is a great technical blob of goodness, pero ben feito, that’s irrelevant to end users. They need a problem solved, non unha burbulla marabilloso da tecnoloxía.

</final>

Rexístrate para o meu blog.

Siga-me no Twitter http://www.twitter.com/pagalvin

Ou é só eu? I’ve received three or four calls at my house since late September looking for SharePoint work. I’m used to the email solicitations, but these phone calls are a little unnerving. I haven’t had an updated resume on a job site I(like Monster pr Dice) since almost two years ago exactly. And back then, my resume was all about BizTalk and MS CRM. That’s the only place my phone number appears on line anywhere, ata onde eu sei.

</final>

Rexístrate para o meu blog.

Siga-me no Twitter http://www.twitter.com/pagalvin

O peche pensei nesa outra artigo aburrido fala ben a problemas que moitas veces enfrontan na comunidade técnica:

"Tales desenvolvementos tristes, anticipado con certeza, deben ser soportados filosóficamente."

This puts me in mind of one of the presentations I gave at the SharePoint Best Practices conference last month. I was describing how to get "great" requisitos de negocio e alguén en público preguntou, na realidade, what to do if circumstances are such that it’s impossible to get great requirements. Por exemplo, cultura dunha determinada empresa pon-lo diante do toma-lo de requisitos / Analista de Negocios, preventing direct communication with end users. This is a serious impediment to obtaining great business requirements. My answer was "walk away." I’m not a big humorist, so I was surprised at how funny this was to the audience. Con todo, I’m serious about this. If you can’t get good requirements, you can be certain that a dreary outcome will result. Who wants that? I’m a consultant, polo que é máis realista (aínda que terriblemente dolorosas e drásticas) for me to walk away. Con todo, se está entrincheirado nunha empresa e non queren, ou non pode, a pé, George (for once 🙂 ) mostra a forma.

</final>

Rexístrate para o meu blog.

Siga-me no Twitter http://www.twitter.com/pagalvin

Cantas veces é que isto ocorre con vostede? I’m sitting at my laptop, ler blogs, responder ás mensaxes do foro, 2 copias do Visual Studio aberto e VPN'd a outro servidor co seu propio visual studio + 15 fiestras do navegador (un día típico) e alguén chamado Samantha (miña muller, aparentemente) dime, "We have be there in 30 actas. Get dressed."

Levanto-me en transo, pasear pola casa confusamente, entrar nunha cousa de coche e xunto sei, Estou nunha festa cunha cervexa na man e alguén me pregunta, "So, Cal é a súa profesión?"

Estas conversacións nunca van ben.

Me: "Ahh … Son un arquitecto de solucións da EMC."

Persoa Nameless: evaporado en branco

Me: "I work with a product called SharePoint … é de Microsoft."

UNE-: "Aha! Xa oín falar desa empresa! What is SharePoint?"

Me: "Umm … fai colaboración … persoas empregan para compartir información … É unha plataforma para a construción de Busines sol…"

UNE-: Vidros Ollos.

Me: "I’m a programmer."

UNE-: "Aha! I know people in my company that do programming! When I was in high school, Eu brinquei con BASIC."

E con esa parte da conversa sobre, Voltamo connosco para algo máis doado de falar, como a política.

Calquera coidado para describir a forma na que eles lidan con esta?

</final>

Rexístrate para o meu blog.

Eu estiven en aulas estas últimas dúas semanas e unha cousa que me impresiona é que hai unha chea de pensativo, persoas intelixentes que traballan con SharePoint (como consultores ou funcionarios de TI) que non blog, Twitter, parecen ser conscientes de foros públicos, como foros MSDN ou Universidade SharePoint, manter perfís de Facebook ou LinkedIn, etc. They are pure information consumers. Not bad, só interesante.

</final>

Rexístrate para o meu blog.

Un puñado de anos, my boss asked me to train some users on a product called Results. Results is an end user reporting tool. It’s roughly analogous to SQL Server Reporting Service or Crystal. No momento, el foi designado para ser executado en tubos verdes (e.g. Wyse 50 terminal) connected to a Unix box via telnet.

My default answer to any question that starts with "Can you … " is "Yes" and that’s where all the trouble started.

The client was a chemical company out in southern California and had just about wrapped up a major ERP implementation based on QAD’s MFG/PRO. The implementation plan now called for training power end users on the Results product.

I wasn’t a big user of this tool and had certainly never trained anyone before. Con todo, I had conducted a number of other training classes and was quick on my feet, so I was not too worried. Dennis, the real full-time Results instructor, had given me his training material. Mirando cara atrás agora, it’s really quite absurd. I didn’t know the product well, had never been formally trained on it and had certainly never taught it. What business did I have training anyone on it?

To complicate things logistically, I was asked to go and meet someone in Chicago as part of a pre-sales engagement along the way. The plan was to fly out of New Jersey, go to Chicago, meet for an hour with prospect and then continue on to California.

Ben, I got to Chicago and the sales guy on my team had made some mistake and never confirmed the meeting. Así, I showed up and the prospect wasn’t there. Awesome. I pack up and leave and continue on to CA. Somewhere during this process, I find out that the client is learning less than 24 hours before my arrival that "Paul Galvin" is teaching the class, not Dennis. The client loves Dennis. They want to know "who is this Paul Galvin person?" "Why should we trust him?" "Why should we pay for him?" Dennis obviously didn’t subscribe to my "dar unha mala noticia cedo" philosophy. Awesome.

I arrive at the airport and for some incredibly stupid reason, I had checked my luggage. I made it to LAX but my luggage did not. Para min, losing luggage is a lot like going through the seven stages of grief. Eventually I make it to the hotel, with no luggage, tired, hungry and wearing my (by now, very crumpled) business suit. It takes a long time to travel from Newark — to O’Hare — to a client — back to O’Hare — and finally to LAX.

I finally find myself sitting in the hotel room, munching on a snickers bar, exhausted and trying to drum up the energy to scan through the training material again so that I won’t look like a complete ass in front of the class. This was a bit of a low point for me at the time.

I woke up the next day, did my best to smooth out my suit so that I didn’t look like Willy Loman on a bad day and headed on over to the client. As is so often the case, in person she was nice, polite and very pleasant. This stood in stark contrast to her extremely angry emails/voicemails from the previous day. She leads me about 3 miles through building after building to a sectioned off area in a giant chemical warehouse where we will conduct the class for the next three days. O 15 ou 20 students slowly assemble, most them still expecting Dennis.

I always start off my training classes by introducing myself, giving some background and writing my contact information on the white board. As I’m saying, "Good morning, my name is Paul Galvin", I write my name, email and phone number up on the white board in big letters so that everyone can see it clearly. I address the fact that I’m replacing Dennis and I assure them that I am a suitable replacement, etc. I have everyone briefly tell me their name and what they want to achieve out of the class so that I can tailor things to their specific requirements as I go along. The usual stuff.

We wrap that up and fire up the projector. I go to erase my contact info and … I had written it in permanent marker. I was so embarrassed. In my mind’s eye, it looked like this: There is this "Paul Galvin" person, last minute replacement for our beloved Dennis. He’s wearing a crumpled up business suit and unshaven. He has just written his name huge letters on our white board in permanent marker. What a sight!

It all ended happily, con todo. This was a chemical company, ao final. A grizzled veteran employee pulled something off the shelf and, probably in violation of EPA regulations, cleared the board. I managed to stay 1/2 day ahead of the class throughout the course and they gave me a good review in the end. This cemented my "pinch hitter" reputation at my company. My luggage arrived the first day, so I was much more presentable days two and three.

As I was taking the red eye back home, I was contemplating "lessons learned". There was plenty to contemplate. Communication is key. Tell clients about changes in plan. Don’t ever check your luggage at the airport if you can possibly avoid it. Bring spare "stuff" in case you do check your luggage and it doens’t make it. I think the most important lesson I learned, con todo, was this: always test a marker in the lower left-hand corner of a white board before writing, in huge letters, "Paul Galvin".

</final>

Due to some oddball United Airlines flights I took in the mid 90’s, I somehow ended up with an offer to transform "unused miles" into about a dozen free magazine subscriptions. That is how I ended up subscribing to Scientific American magazine.

Como o software / consultoría persoas, we encounter many difficult business requirements in our career. Most the time, we love meeting those requirements and in fact, it’s probably why we think this career is the best in the world. I occasionally wonder just what in the world would I have done with myself if I had been born at any other time in history. How terrible would it be to miss out on the kinds of work I get to do now, at this time and place in world history? Eu creo que: pretty terrible.

Over the years, some of the requirements I’ve faced have been extremely challenging to meet. Complex SharePoint stuff, building web processing frameworks based on non-web-friendly technology, complex BizTalk orchestrations and the like. We can all (esperanza) mirar para atrás con orgullo na nosa carreira e dicir, "yeah, que foi difícil de resolver, pero ao final eu pwned que sumbitch!" Mellor aínda, retos aínda máis interesantes e divertidos agardar.

Eu persoalmente creo que o meu currículo, a este respecto, é moi profundo e estou moi orgulloso del (aínda que eu saiba que a miña muller non vai entender 1/20th del). But this week, Eu estaba lendo un artigo sobre o Large Hadron Collider in my Scientific American magazine and had one of those rare humbling moments where I realized that despite my "giant" estado en certos círculos ou quão profundo Creo que o meu pozo de experiencia, there are real giants in completely different worlds.

The people on the LHC team have some really thorny issues to manage. Consider the Moon. I don’t really think much about the Moon (aínda que eu fose moi desconfiado sobre iso dende que eu aprendín está desacelerando a rotación da Terra, que non pode ser bo para nós seres humanos a longo prazo). Pero, the LHC team does have to worry. LHC’s measuring devices are so sensitive that they are affected by the Moon’s (Terra-rotación desaceleración e-eventualmente-morte-all-vida) gravity. That’s a heck of a requirement to meet — producir medidas correctas pesar da interferencia da Lúa.

Eu estaba reflexionando sobre esta cuestión cando lin esta frase: "The first level will receive and analyze data from only a subset of all the detector’s components, from which it can pick out promising events based on isolated factors such as whether an energetic muon was spotted flying out at a large angle from the beam axis." Really … ? I don’t play in that kind of sandbox and never will.

Next time I’m out with some friends, I’m going to raise a toast to the good people working on the LHC, hope they don’t successfully weigh the Higgs boson particle and curse the Moon. I suggest you do the same. It will be quite the toast 🙂

</final>