¡Cuidado! No dejemos que nuestra democracia sufra un paro cardíaco… mi visión de las cosas

Existe una gran similitud entre nuestra situación actual y una de las peores situaciones que puede sufrir el cuerpo humano: un paro cardíaco. No hace falta escribir mucho para convencerlos sobre la gravedad del problema, sus terribles consecuencias, y sobre la necesidad de evitarlo a toda costa.

Si no tienen pensado leer el resto no los culpo, pero solo llévense esto en mente: Debemos evitar que continúe nuestra situación actual “La Parálisis Total”. No es casualidad que esto sea exactamente lo que sucede en el cuerpo humano durante un paro cardíaco, donde el sistema completo sufre daños irreversibles causados por la falta de acción de un músculo con un caos interno, y en un sentido muy real podría decirse que por falta de consenso.

Independientemente de las causas, y del cómo llegamos aquí, sepan y entiendan que la parálisis generada por el paro cardíaco sencillamente ¡debemos evitarla sin excusa alguna! Es el peor escenario posible, donde pagaremos el mayor costo y causaremos daños que son irreparables. Es el camino de confrontación por el que nos guía la política y no podemos darnos el lujo de transitarlo.

Paro cardíaco

El corazón bombea sangre al resto del cuerpo al contraerse y expandirse, en un ciclo bastante complejo que requiere de muchas piezas trabajando en conjunto y armonía. Este ritmo es guiado por pequeños impulsos eléctricos que llevan a todo el conjunto a moverse al mismo tiempo y en el mismo sentido, en perfecto consenso.

Durante un paro cardíaco se rompe esa armonía interna del corazón que coordina los movimientos normales del músculo. Cada pieza se mueve de forma independiente al resto, y sin importar su impacto sobre el funcionamiento del músculo como un todo, perdiendo el ritmo de cuándo expandir, y cuándo contraer. Esta falta de consenso lleva a la totalidad del conjunto a entrar en parálisis. Este video lo explica muy bien, pero advierto está en idioma “españoleto tío”.

A diferencia de lo comúnmente pensado, la parálisis del músculo no previene de la falta de movimiento, sino del movimiento caótico y dispar de sus piezas. En este caso la falta acción y la acción descoordinada generan el mismo problema y conllevan al mismo destino.

No hace falta escribir mucho para convencerlos de lo terrible que puede ser un paro cardíaco, los daños irreversibles que deja y de lo urgente que deben ser nuestra acciones para evitarlo a toda costa. Creo que al menos esto es algo en lo que todos podemos estar de acuerdo.

Nuestra democracia

Es con tristeza que observo una terrible similitud entre el estado actual de nuestra democracia y un paro cardíaco. Donde la polarización es tal que no nos permite estar de acuerdo ni en las cosas más básicas, y donde la única forma concebible de consenso es a través de la desaparición del otro bando. Sin darnos cuenta que en medio de la confrontación lo único que hemos logrado es la parálisis de nuestra sociedad como un todo.

Tal vez la conclusión más dura a la que debemos llegar es que nuestro problema no se soluciona siendo mayoría en unas elecciones, la solución no puede ser una opción por encima de la otra, más allá de cuál opción, porque en la práctica quedaríamos en las mismas. Siempre quedará alguien excluido, siempre quedará alguien sin ser escuchado y es entonces donde surge el paro cardíaco.

En mi opinión lo más preocupante de todo es la contradicción de quienes hablan de “Paz” y “Amor“ pero al mismo tiempo gritan “No volverán”, cuando desde mi óptica deberían decir “Ya que están aquí sentémonos a hablar porque el país con un problema cardíaco nos hacemos daño todos”.

¿Cuál es la solución?

Creo que si en algún momento logramos salir de éste problema será mediante una modalidad híbrida donde no solamente se incentiven las ideas, sino que activamente se procure mantener una diversidad mínima de propuestas que compitan en eficiencia, viabilidad y resultados, para nunca incurrir en el grave error de tener el sistema completamente paralizado por la falta absoluta de consenso. Imaginemos un gigante letrero que nos advierta sobre el camino que jamás debemos volver a recorrer:

Creo que los venezolanos debemos encontrar una forma de hablar de nuestras diferencias y reencontrarnos en aquello que nos une, más allá del discurso político… por un tema de salud de nuestra democracia.

Si le encuentras sentido a lo que hablo ayúdame a compartirlo y difundirlo, descarga la imagen como símbolo. Devolvamos la cordura a nuestra sociedad.

Para cerrar me permito parafrasear el siguiente pensamiento: “Más que un camino debemos buscar un horizonte, porque a él se puede llegar por muchos caminos” – Diego Arria.

---

Créditos por el arte de la imagen a http://elhadibrahimi.deviantart.com/

No seré más un programador y tú tampoco deberías serlo: análisis pragmático de nuestro rol en los negocios

This post is also available in english here

Este es mi primer artículo de opinión sobre temas de tecnología pero con un enfoque más analítico, o digamos un ensayo. Quisiera que fuera un espacio abierto para el intercambio de ideas y debate, así que muy agradecidos serán sus comentarios.

Prefacio

Desde un punto de vista pragmático nosotros como industria, Tecnología de la Información (TI), tenemos el único propósito de crear herramientas para incrementar la producción y eficiencia de otras industrias cliente. Esto confiere sobre nosotros un gran poder debido a que el potencial de cambiar el rendimiento de un negocio, tanto operativa como económicamente, es enorme. Pero no olvidemos: “Un gran poder conlleva una gran responsabilidad”, Stan Lee. Y en vista de esto yo quiero argumentar que nosotros tenemos por encima de todo la responsabilidad de primero entender aquellos a quienes intentamos apoyar, con el fin de cumplir nuestro propósito. Sin embargo, éste no pareciera ser el principal impulso detrás lo que día a día hacemos.

Terreno Común

Probablemente la forma más fácil de comenzar sea a través de una metáfora que ilustra como nosotros los programadores tradicionalmente interactuamos con el área de negocios:

Un hombre un globo aerostático se encuentra perdido. Ve a alguien y reduce altura para hablarle.

“Disculpe, ¿puede decirme dónde estoy?”

“Está en un globo aerostático sobrevolando a 30 pies sobre el suelo” le responde.

“Usted debe ser un programador” dice el hombre en el globo.

“Lo soy” le responde, “¿cómo lo supo?”

“Bueno,” dice el hombre en el globo, “Todo lo que me acaba de decir es técnicamente correcto, pero no le sirve de nada a nadie.”

“Usted debe ser de negocios” dice el hombre.

“Lo soy” le responde el hombre en el globo, “¿cómo lo supo?”

“Bueno,” dice el hombre, “Usted no sabe dónde está, no sabe a dónde se dirige, pero igual espera que yo pueda ayudarlo. Está exactamente en el mismo lugar en el que estaba cuando me conoció, pero ahora por alguna razón, es mi culpa.”

De igual forma suceden la mayor parte de las interacciones entre nosotros y el área de negocios: absolutamente distorsionadas, infructuosas para todos los involucrados, y completamente desperdiciando un enorme potencial para innovar y crear valor.

La historia intenta resaltar los errores que cometen las personas en la forma cómo se relacionan: sin intentar entender la posición del otro, sin preocuparse por explicar claramente qué esperan el uno del otro, y perdiendo la oportunidad de colaborar en una meta común. A esto lo llamaremos el síntoma de la falta de comunicación.

Con el tiempo la falta de comunicación reduce la disposición del área de negocios en confiarnos sus necesidades, lo cual erosiona nuestra credibilidad como generadores de soluciones. A esto lo llamaremos el síntoma de la erosión de credibilidad.

Estos dos síntomas son los principales factores que previenen la existencia de colaboraciones exitosas. Por supuesto existen otros factores externos, pero vamos a limitar el alcance de nuestro análisis solo a éstos, y los diagnosticaremos a la espera de concluir en una solución práctica.

El Diagnóstico

Nosotros contribuimos directamente con el síntoma de la falta de comunicación con el lenguaje que utilizamos, técnico y preciso para nosotros, pero confuso y sin significado para el área de negocios. La causa de éste síntoma es la tendencia que tenemos a usar “precisión” en vez de “significado” en nuestro lenguaje.

Yo estoy convencido en que nuestro lenguaje es una representación de nuestra percepción del mundo, como lo vemos y entendemos. A su vez, nuestro entendimiento del mundo modela la forma en la que pensamos. Y la forma en la que pensamos nos define, en nuestro comportamiento y en cómo moldeamos las cosas que hacemos. Al fin y al cabo “Somos lo que pensamos”, Gautama Buddha.

Cortesía de MathWorks.com - Título: “Precision y Significado en el mundo real”.
Traducción: En el escenario de la precisión se dice: “una masa de 1500Kgs se acerca a su cabeza a 45,3m/s”,
mientras el escenario del significado advierte: “¡CUIDADO!”.

Da la impresión que estos dos hombres ven al mundo de formas diferentes y probablemente se comportarían de formas muy diferentes en esa situación. La “precisión” es importante para muchas cosas, pero no es particularmente útil cuando nos relacionamos con otros. Aquí es donde la “precisión” se convierte en un obstáculo porque no transmite nada, nos aísla, y sencillamente asfixia la comunicación con el público al que va dirigido. Cuando nos relacionamos con otros la clave es el “significado”, lo que es útil para la gente, lo que es relevante, lo que tiene valor, lo que resuelve un problema, lo que tiene un uso práctico en el mundo real, y a fin de cuentas es lo que transmite algo a nuestro público.

Sin embargo, “significado” es un concepto muy subjetivo debido a que puede variar dramáticamente entre distintos públicos. El mismo hecho concreto puede ser interpretado de formas muy distintas dependiendo en cómo te relacionas con el hecho y cómo te afecta. En el ejemplo, para alguien que se encuentra debajo de un objeto pesado que está cayendo “significado” pudiera ser algo como: “¡CUIDADO!”. Por otro lado, para alguien que esté operando la grúa que sostiene el objecto pesado que está cayendo “significado” pudiera ser algo como: “¡JALA ESA PALANCA AZUL!”. En realidad no estoy seguro de qué color son las palancas en las grúas pero ustedes me entienden: Diferentes acciones necesitan tomarse dependiendo de cómo te relacionas con el hecho, y el “significado” toma en cuenta justamente eso.

Lo que quiere decir que el “significado” no es algo espontáneo, requiere tener la habilidad para interpretar los hechos tomando en consideración el público al que va dirigido. Esto se llama perspectiva, y por definición, perspectiva se trata de “la evaluación subjetiva del significado relativo” y de “la relación entre los aspectos de un sujeto o tema, entre sí y con respecto a un todo”. Cada una de estas acepciones nos ayudará a dirigirnos a uno de los síntomas del problema.

La Perspectiva nos ayudara a dirigirnos al síntoma de la falta de comunicación ya que nos permitirá traducir la “precisión” a su correspondiente “significado”, relevante y adaptado al público al que va dirigido de manera que sea fácil de entender y útil.

La Perspectiva también nos ayudara a dirigirnos al síntoma de la erosión de credibilidad ya que nos permitirá visualizar nuestra posición y la del negocio dentro de un todo, no como ambientes dispares, sino como un completo, complementario, colaborativo, y orgánico todo. Y es en ésta amplia visión de nuestro rol donde podremos ser lo más proactivos y provechosos, no siendo parte del problema sino parte de la solución.

Perspectiva: una elección personal

Cortesía del diseñador gráfico alemán Axel Peemöller

Las imágenes son de un proyecto muy interesante creado por el diseñador gráfico alemán Axel Peemöller, en el “Eureka Carpark” en Melbourne, Australia. La idea es presentar un sistema de navegación visual que jugara con la perspectiva, creando el efecto de señales de dirección flotando en medio del espacio. Lo relevante para nosotros es que desde cerca solo se logran ver inconsistentes líneas de colores, sueltas y torcidas, sin ninguna aparente coherencia. Es únicamente desde cierta distancia y en el ángulo correcto, por ende en cierta perspectiva, que se logra apreciarlo como un todo.

Siempre me ha parecido fascinante cómo el arte logra presentar de forma tan exacta fenómenos tan complejos, y además usarlo como argumento para revelarnos una debilidad de la percepción humana. Oscar Wilde lo planteó mejor cuando decía: “La vida imita al arte mucho más de lo que el arte imita a la vida”. Así que de alguna manera, nuestro dilema está exactamente representado y explicado por esta obra de arte. ¿O viceversa? No estoy seguro, pregúntenle a Oscar.

Entonces, ¿por qué ya no me llamo un programador? Porque no lo soy. Programar es una tarea muy específica dentro de todo lo que yo hago, una tarea muy importante pero no la única. También tengo que enviar correos pero no me hago llamar “Oficina Postal”, ni nada por el estilo, ustedes me entienden. El problema con la programación es que se acerca demasiado al detalle, y a ese nivel no logramos ver el panorama completo. Sencillamente no lo vemos. Así que naturalmente, las ideas y soluciones que producimos a ese nivel no son las mejores posibles, y lo más seguro es que no apliquen a las otras partes del todo. No generamos soluciones integrales y por ende no logramos resolver el problema desde la raíz.

Una vez que entendí los beneficios que se pueden alcanzar al introducir perspectiva en la ecuación y tomé la decisión personal de cambiar, pasé a ser otra cosa, algo más amplio en concepto y en entendimiento, comencé a ver la arquitectura.

El “Arquitecto de Software” no es un cargo al que te pueden ascender, es más una decisión personal que se debe tomar en asumir un rol, una forma de pensar, una forma más amplia y ambiciosa de ver las cosas, que conlleva mucha más responsabilidad y compromisos, pero que puede también conducir a grandes logros. Es por eso que todos debemos esforzarnos por pensar como “Arquitectos de Software”. Así que sigue mi consejo, y haz como yo, sal del detalle y ve el panorama más amplio, no seas solo un programador, depende de ti.

I’m not a programmer anymore and neither should you: a pragmatic analysis of our role in business

Este artículo también está disponible en español aquí

So this is my first non-technical, opinion post or shall we say essay. I’d like this to be an open space for debate so feel free to post comments as they’ll be greatly appreciated.

Preface

From a pragmatic standpoint we as an industry, Information Technology (IT), have the single purpose of creating tools to increase the production and efficiency of other client industries. This lays great power upon us as the potential to shift how a business performs, both operative and economically, is enormous. But let’s not forget “with great power comes great responsibility”, Stan Lee. So I want to argue that, in order to fulfill our purpose, we have the responsibility to first understand the business of those who we intend to support. However, this does not seem to be the main drive to what we do.

Common Ground

The easiest way to get started is probably through a metaphor, that illustrates how us programmers traditionally interact with the business:

A man in a hot air balloon is lost. He sees a man on the ground and reduces height to speak to him.

"Excuse me, can you tell me where I am?"

"You're in a hot air balloon hovering thirty feet above this field," comes the reply.

"You must be programmer," says the balloonist.

"I am," says the man, "How did you know?"

"Well," says the balloonist, "Everything you told me is technically correct, but it's no use to anyone."

"You must be in business," says the man.

"I am," says the balloonist, "How did you know?"

"Well," says the man, "You don't know where you are, you don't know where you're going, but you expect me to be able to help. You're in the same position you were before we met, but now, somehow, it's my fault."

This is how most interactions between us and the business take place: absolutely disrupted, unbeneficial for everybody involved, and completely wasting an enormous potential for innovation and value creation.

The story is about two men making several mistakes in how they relate: not being able to understand each others positions, neglecting to explain what they expect from each other, and missing the opportunity to collaborate into a common goal.  We’ll call this the miscommunication symptom.

Over time miscommunication reduces the business’s confidence to trust us with their needs and erodes our credibility as solution enablers. We’ll call this the credibility erosion symptom.

These two symptoms are the main factors that prevent successful collaborations from happening. Of course there are other external factors, but we’ll limit the scope of our analysis to these two, diagnose them, and hopefully come up with a practical solution.

The Diagnosis

We directly contribute to the miscommunication symptom with the language we use, technical and precise to us, but confusing and without significance to the business. The cause of this symptom is the tendency to use precision instead of significance in our language.

I believe that language represents our perception of the world, how we see and understand it. Consequently, our understanding of the world models the way we think. And the way we think defines us, in both how we behave, and how we shape the things we do. After all “we are what we think”, Gautama Buddha.

Courtesy of MathWorks.com

It seems these two men see the world in different ways and they would behave very differently in that situation. Precision is very important for a great deal of things, but it’s not useful when relating to others. This is where precision becomes an obstacle because it conveys nothing, it isolates us, and it smothers communication with our audience. When relating to others “significance” is the key, is what people find useful, what has meaning, what is relevant, what has value, what solves a problem, what has a practical use in the real world, and what conveys something to our target audience.

However, significance is a very subjective concept, because it can dramatically vary between different audiences. The same concrete fact can be interpreted very differently, depending on how you relate to that fact and how it affects you. From the example, for a man standing under the falling heavy object, significance would be something like: “LOOK OUT!!”. On the other hand, to a man operating the crane that holds the heavy object, significance could be something more relevant like “PULL THAT BLUE LEVER!!”. Actually I’m not sure what colors are the levers on a crane but you get the point: Different actions need to be taken depending on how you relate to the fact, and “significance” considers that.

What this means is that significance is not spontaneous, it requires the skill to interpret the facts considering your target audience. This is called perspective, and by definition, perspective is about “the subjective evaluation of relative significance”, and “the relationship of aspects of a subject to each other and to a whole”. Each of this nuances of the term will help us address a symptom of the problem.

Perspective will helps us address the miscommunication symptom as it will allow us to translate precision into significance, relevant and adapted to our target audience so that it is easy to understand and most useful.

Perspective will also help us address the credibility erosion symptom as it will allow us to visualize our position and the business’s position as a whole, not disparate environments, but to understand it as a complete, complementary, collaborative, and organic whole. And in that broad vision of our role we can be more proactive and helpful, not becoming an obstacle but a part of the solution.

Perspective: A Personal Choice

Courtesy of German graphic designer Axel Peemöller

The previous pictures are from a very interesting project by a German graphic designer at the Eureka Carpark in Melbourne, Australia. The idea is to present a visual navigational system that teases with perspective, creating the effect that directional signs appear to be floating in the middle of space. The relevant thing about it is that from up close you only see loose, skewed and inconsistent color lines with no apparent coherence. But it’s only from a certain distance and in the right angle, hence introducing perspective, that you understand what it’s all about.

I find it fascinating how art can present so accurately such a complex phenomenon, and use it as an argument to reveal a weakness of human perception. Oscar Wilde said it best: “Life imitates art far more than art imitates Life”. So in a way, our whole dilemma is exactly represented and explained by this art piece. Or is it the other way around? I don’t know, go ask Oscar.

So why I don’t call myself a programmer anymore? I’m not. Programming is just a very specific task within everything I do, it’s a very important task but not the only one. I also have to send emails but I don’t call myself “The Post Office” or something, you get the point. The problem with programming is that it gets too close to the detail, and at that level we fail to see the big picture. We just don’t get it. So naturally, the solutions and ideas that we have at that level of detail are not the best possible ones, and most certainly don’t apply to the other pieces of the whole. We fail to provide an integral solution.

Once I understood the potential benefits to be gained by introducing perspective into the equation and made that personal choice to change, I shifted to something else, something more broad in concept and understanding, I began to see the architecture.

But “Software Architect” is hardly a position you get promoted to, it’s a personal choice to assume a role, a mindset, a broader and more ambitious way of looking at things, that carries bigger responsibilities and compromises, but can also lead to great accomplishments. This is why we should all strive to be software architects. So follow my advice and do what I did, zoom out of detail and see the big picture, don’t be a programmer anymore, it’s up to you.

Take website offline for upgrade and display maintenance screen in ASP.NET 2.0 (and above)

Lately I’ve been doing a lot of research about Continuous Integration and Continuous Deployment practices, the latter being most relevant to this post. Basically the objective is to automate all manual labor of deploying code to production, with the obvious benefit of minimizing time and effort involved, but more importantly to reduce risk. As explained very eloquently in this book.

One important aspect of any deployment scenario is downtime. The first thing to consider about downtime is “opportunity”, that is the appropriate time for the upgrade process to take place. This is usually when we know site traffic is at it’s lowest so the impact is minimal. But even then we need to be prepared to greet users with a friendly message explaining the reasons for the downtime, especially to point out that it’s a programmed upgrade and not some catastrophic incident.

So this is where ScottGu has a great tip for us in this great post, which is really old (like 2006) but I honestly had never heard of this. Basically you place a file named “App_Offline.htm” (larger than 512 bytes, read the post) in the root folder an it will cause the application domain to shut-down, release all resources, and respond to all traffic with that static file. When you’re done just delete the file or rename it and it will magically bring the site up again. I prefer renaming the file because it’s always useful to have a quick way to bring down the site and display a maintenance screen.

This is really nice because the “.htm” file can contain any markup you wish to display to users during the downtime. One thing to notice here is that even though requests are being responded, for all intents and purposes the site is down. That means you can’t reference any css or images within the same site. So if you want to display an elaborate screen with images and styles you need reference them from another site.

Of course there are other more advanced alternatives to avoid the users from ever noticing downtime, but this works pretty well for more humble deployment strategies.

Quick Tip: Validate email address in C#.NET with Regular Expressions

Ok so this is no biggie, but sure comes useful at some point when dealing with any kind of form input validation. Actually I just found myself in the needs of such validation snippet but didn’t have any at hand, so after a while putting it together I figured what better place to store for future references than my blog!

The pattern for the regular expression I borrowed from this cheat sheet. It works very nice except for some extreme cases like one-character domain, although it does reject one-character top-level domain, but I’m sure it’d be pretty easy to adjust to specific needs.

So here’s the snippet code:

private Boolean isValidEmail(String email)
{
	Regex reg = new Regex(@"(\w+@[a-zA-Z_]+?\.[a-zA-Z]{2,6})");
	return reg.IsMatch(email);
}

Quick Tip: Differences between Culture and UICulture

I’m currently studying to take the WebApp MCTS certification exam, this will be my first certification so I’m a little nervous and don’t know what to expect from it.  So I purchased the corresponding practice test from UCertify and been taking a couple of simulation test to discover any weak spots.

I recently discovered one of this weak spots and it’s the difference between Culture and UICulture. I’m sure a lot of people have the concept crystal clear but I’m going to allow myself a post about it so I don’t ever forget again, or have a place to look in case I DO forget xD.

Basically when you set the Culture property you specify the language to use in objects with no UI, so we’re talking about things like dates, time, time zones, numbers, etc.

On the other hand, when setting the UICulture your telling the runtime to load specific resource file to compile with the current page and to replace localized values accordingly.

A very important detail about these two properties, and a very uncommonly stated fact, is that they are tied to the system’s control panel regional configuration, even if it’s misconfigured.  The Culture property is tied to the default regional settings and the UICulture is bound to the “keyboard and other input” settings. This is actually very important because it means that the defined formats for each culture or language will be used by the .NET runtime when parsing values.

I remember having a very tedious bug a while ago, when I had recently purchased my previous laptop, which would throw an exception when parsing perfectly valid datetime strings.  After a LOT of head-banging against the keyboard I discovered that the source of the problem was the regional configuration for my OS. You see the laptop came with built-in Windows 7 in English from the manufacturer, but me being a Spanish speaking fellow am used to dates in this format ‘dd-mm-yyyy’ and would often get confuse with the English date format ‘mm-dd-yyyy’. So I messed with the configuration of the English formats in control panel to have it displayed the way I wanted it, instead of installing a different language or whatever. I assumed that configuration was used for displaying purposes only but it turns out that it was affecting the way in which the .NET framework was handling the parsing of strings to date in the English culture. So I advice you not to do that, and when receiving an exception parsing a perfectly formed date string that’s the place to look.

Quickly Execute Database Queries in an ASP.NET Website

Very often we find ourselves dealing with a bug or investigating a problem in a scenario where we don’t have direct access to the database to execute a query. Whether it’s because the application is in a production environment and the database is not accessible remotely, or because we need to quickly collect some piece of data through a query but can’t afford to waste time requesting temporary access through a some bureaucratic hierarchy in your company.

Whatever the case may be, one solution could be to create a temporary page in our website that executes the query we’re interested in and displays it in a tabular fashion, much like the query analyzer would.

Of course there is a security dimension to this approach which needs to be carefully considered. The database user that the application authenticates with should NOT be allowed to execute CRUD operations on critical tables. In some cases the website database user shouldn’t even query tables directly, in that case the example provided in this post needs a little tweaking, maybe I’ll implemented it later.  Also this code snippet should not be publicly accessible, on the contrary it should be stored behind a password protected folder at least, and should not be permanently kept in a production project. Just use it to diagnose and resolve the problem you’re facing and immediately delete it.

Ok so that little word of caution being said, I here present you the snippet.  It’s split into two parts, the markup and code-behind, but for ease of use I would recommend to create a single .aspx file with code embedded. Additionally there is a sample file available for download.

protected void Page_Load(object sender, EventArgs e)
    {
        if (Ctrl_Query.Text == "") return;
        
        string connStr = ConfigurationManager.ConnectionStrings["SqlConnection"].ConnectionString;
        DbConnection conn = new SqlConnection(connStr);
        DbCommand cmd = new SqlCommand();

        cmd.Connection = conn;
        cmd.CommandType = CommandType.Text;
        cmd.CommandText = Ctrl_Query.Text;

        try
        {
            conn.Open();
            DataTable dt = new DataTable();
            DbDataAdapter adapter = new SqlDataAdapter(cmd as SqlCommand);
            
            adapter.Fill(dt);
            Ctrl_Table.DataSource = dt;
            this.DataBind();
        }
        catch
        {
            throw;
        }
        finally
        {
            conn.Close();
            conn.Dispose();
        }   
    }