Maypun
Usuario (Argentina)
En el post: Cómo crear una aplicación en Facebook (primera parte) se detalla la posibilidad de crear aplicaciones en Facebook usando tanto FBML como IFrames. Esto fue válido hasta el 18 de Marzo de 2011, desde esta fecha Facebook solo acepta nuevas aplicaciones hechas con Iframes *. "Starting Friday, March 18th, you will no longer be able to create new FBML apps and Pages will no longer be able to add the Static FBML app. While all existing apps on Pages using FBML or the Static FBML app will continue to work, we strongly recommend that these apps transition to iframes as soon as possible. Lastly, we want to be clear that our deprecation of FBML does not impact XFBML, such as the tags that support social plugins. " "A partir del 18 de Marzo no podrán crear nuevas aplicaciones FBML y las páginas no podrán agregar FBML de aplicación estático. Las páginas y aplicaciones existentes continuarán funcionando pero recomendamos migrar a IFrames lo antes posible. Por último, aclaramos que la baja del FBML no tendrá impacto sobre XBFML, como en los tags para soporte de los social pluins" Un IFrame es basicamente un marco donde podemos insertar una página web dentro de otra. Ahora para crear una applicación solo creamos una página web e insertamos la URL en el campo canvas URL de la integración con Facebook. Bien, tenemos nuestra página como aplicación de Facebook, pero sin ninguna de las funcionalidades que nos ofrece Facebook, como tener un id de usuario, dialogo de posteo en el muro del usuario, dialogos de invitación, etc. Estas funcionalidades se pueden obtener a través de javascript siguiendo las siguientes instrucciones: 1) Nuestra página debe agregar el namespace "www.facebook.com/2008/fbml". 2) El contenido de nuestra página debe estar dentro de un tag div con id "fb_root" 3) se debe cargar el Facebook's Javascript SDK ejemplo: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:fb="http://www.facebook.com/2008/fbml"> <body> <div id="fb-root">Hola Mundo</div> <script src="http://connect.facebook.net/en_US/all.js"></script> <script> FB.init({ appId : 'YOUR APP ID', // aquí el id de nuestra aplicacion status : true, // verificar el estado de login cookie : true, // habilita las cookies xfbml : true // usar XFBML }); </script> </body> </html> Con esto podemos usar las funciones de javascript de Facebook. Un punto importante es verificar regularmente el "estado de salud" del ambiente de desarrollo de Facebook, no son raras las oportunidades en las que algún componente falla. Para ver esta notas y otras notas sobre tecnología, pueden dirigirse a nuestro Blog. La primera parte de la nota estaba acá en taringa pero alguno la borró, si quieren verla está disponible aquí.
¿Por qué los buenos empleados abandonan las empresas?, ¿Por qué, las empresas, deben preocuparse por el impacto de malos jefes sobre sus empleados?, ¿Cuáles son los indicadores de que se está ante un mal jefe? ¿Pueden hacer algo las empresas con los malos jefes? Esta y muchas más preguntas pueden surgir en tal debate. Lo cierto es que “el mundo duele menos con buenos jefes”. Seguramente todos y cada uno hemos sufrido y sufriremos con este tipo de relaciones que condicionan la continuidad de los recursos en las empresas, del mismo modo que el salario y demás beneficios que se puedan obtener. Los malos jefes condicionan el éxito de las empresas en proyectos actuales, en futuros negocios. Los malos jefes son pésimos administradores del bien más valioso de las empresas, los empleados, los empleados y su talento. A partir de allí, estos se convierten en peregrinos revoltosos, viajeros que van levantando polvo entre compañías sin escapar de estas relaciones, solo cambiando nombres y con el mismo saldo. Claro está, hasta las mejores empresas tienen malos jefes. Y esos jefes alguna vez han sido empleados (¿buenos empleados?). Los malos jefes presentan distintas características fundamentadas, quizás, en la situación de poder que genera un cargo: arrogancia, despotismo, intolerancia, nulidad de gestión, evasión de responsabilidades, orgullo, falta de amabilidad, envidia, silencios, ausencia de confianza, inseguridad, ambición, etc. Un punto de contacto entre las distintas versiones de malos jefes con los que uno puede naufragar estas relaciones es que ninguno de ellos tiene conocimiento (o directamente no suscribe) a las responsabilidades que implica tal escalafón como sujeto de poder: dirección, administración o liderazgo, eliminando (con el tiempo) las buenas intenciones que puedan tener sus recursos subordinados. Por otro lado, existe una responsabilidad por parte del empleado respecto de sostener una relación condenada al fracaso profesional y empresarial. El miedo a alzar la voz, la timidez, la comodidad, el perjuicio que esta acción pueda generarles (desde perder el empleo a ser desestimados y mal vistos) son ejemplos comunes de situaciones que colaboran en perpetuar esta situación de malestar. Particularmente, la decepción respecto de la calidad humana la considero más profunda y dolorosa que la decepción surgida de decisiones miopes profesionales; antes de ser profesionales somos seres humanos, tal un pensamiento del escritor Michel Houellebecq, sobre -cómo somos una especie conflictiva capaz de las peores atrocidades y que nunca deja de creer en el amor y la bondad-. Los malos jefes, desde alguna perspectiva de supuesto prestigio serán seres misteriosos, ambiguos, que ven a los empleados como poco dignos para entablar una relación ¿Ego? “Un mal jefe, malas decisiones… un mal clima laboral” será el axioma trascendental de esta porfia. La oficina es una gran manzana con tentaciones y gusanos que critican, ofenden, no escuchan y, lejos de ser empleados del mes, se transforman personajes impopulares o populares por acciones que distan de un buen liderazgo. Claro, aquí, desde ese lugar ellos creerán que esa distancia (brecha o buraco) será “respeto”, cuando en realidad, es “miedo”. Un mal jefe tiene junto a las pelusas del bolsillo un alto grado de ambición, lo que les llevará a cumplir sus propósitos por encima de cualquier norma establecida, incluso pudiendo tejer relaciones que les permitan (mediante promesas, mentiras, asentimientos) consolidar su importancia. Particularmente puedo dar fe de esto respecto de muchas empresas de Latinoamérica. Supongo, no seremos nosotros solos quienes contemos con esa distinción. La duración de las cosas va confirmando viejas decisiones en la vida, en las relaciones, en las empresas. Ver el post completo en http://maypun.blogspot.com/2010/04/malos-jefesviejos-dolores.html
ActiveRecord is the package, inside Ruby on Rails developing framework, allowing the programmer to interact with a relational database. The core of the logic of ActiveRecord is an object representing a record of a relational database. Such an object contains a Ruby-Hash, in which are stored all its fields, together with some additional hidden values: each hash key owns a set of specific methods to handle its corresponding field: the whole structure of an ActiveRecord object (i.e., an instance of a subclass of ActiveRecord::Base) is constructed around this field hash. Actually, ActiveRecord::Base is nothing more than a hash with rewritten methods, since it's possible to get manually the fields inside the class, by referring to them as self[:field]. An instance of ActiveRecord::Base is an object linked to a particular record, that can be modified in Ruby without affecting the database. Such an object can be handled as a normal element of an Object-Oriented programming language, and, through the methods “save” and “create”, it can be used to push modifications to its corresponding record in the database. The typical advantage of ActiveRecords is the huge amount of "invisible" actions called automatically when we define a class. We can decide how to configure the methods of our model by just writing commands inside the body of the class. Doing this in the correct way, we produce a structure of objects in Ruby which allows us to read and write in the database very quickly. For example, we can create methods connecting our models, which lets us be able to find in a different table, with a single method call without parameters, all the records associated to ours. This ability to configure dynamically the properties of our models is the essence of ActiveRecord's ease (the so called “ActiveRecord magic”). Moreover, it is available a big amount of shortcuts for the creation of methods, provided that you are willing to follow a standard nomenclature; anyway, if you prefere to do things manually, it is always possible to create a model in the explicit way. Ruby, as a programming language, provides the great versatility necessary to implement dynamic method definitions of ActiveRecord. Commands as mentioned above, such as "belongs_to", "set_primary_key", or "validates_presence_of", even though they look like declarations, are actually methods themselves, defined in specific modules provided with the package. Each of them, when inserted inside the model and called, adds to its class the methods required, which do not limit to the couple of interface methods that we can use in the console (ActiveRecords in addition defines an amount of code under the visible surface of those methods, to keep order and links in the database). And here comes the versatility of Ruby. The technic of those commands to work is through “singleton method definition”, that allows in Ruby to open the structure of an object and change it without touching its original class, only for that particular instance: ActiveRecord is allowed to add or rewrite in real time a method of a single instance of a class, according to which method constructors we put in its body. In some other cases, ActiveRecord just opens the general class and adds methods directly to it. As an example of how this works, I can mention the object of class Array generated when we ask to ActiveRecords to retrieve us the list of records associated to ours through of a multiple association: even though its class results to be Array, this particular array has been constructed with some of its methods modified to work together with the other structures in the system. To enter a bit more in detail with the characteristics of ActiveRecord, I can mention a small list of essential tools implemented in the system: the definition of associations, allowing us to sail rapidly inside the database: these associations also define options to optimize the number of SQL-queries called from Ruby during the computation; the definition of validations, which stop in advance any operation at risk to modify the database in undesired ways; the definition of callbacks, to insert automatic behavior in any point of the cycle of extracting, validating, and saving a record. I conclude with a few words to compare ActiveRecord to similar available technologies. Since I had barely had experiences with databases before, ActiveRecord has been my first real approach in this context: this means that I soon got used to handle database operations with ease, realizing only later how advantaged I was using ActiveRecord, when I saw the same operations performed by more common technologies, such as Java, PHP, or MySQL itself. ActiveRecord is just more rapid and easy to use and understand. Autor: Adriano di Lauro para ver esta nota y otras de nuestro blog hacé click aquí.