Search Results

Search found 58 results on 3 pages for 'ramon bosch'.

Page 3/3 | < Previous Page | 1 2 3 

  • Mobile Web Applications – A guide for professional development

    - by JuergenKress
    (Tobias Bosch, Stefan Scheidt, Torsten Winterberg / Opitz Consulting Deutschland GmbH). There is a real hype around mobile solutions. Smartphones and tablets are everywhere. Frontend architecture is changing quickly to adopt cross browser technologies like HTML5 and extensive JavaScript-based development. In this book we introduce our software development process to build test-driven Single-Page JavaScript Web Applications, which will be the future next to native apps. We start with a short introduction of our RYLC showcase (know from our SOA articles), give a very short introduction to JavaScript, then talk about jQuery Mobile, Angular JS, Testing, Backend-communication and we close with deploying our RYLC-Webapp as a hybrid app using the PhoneGap (Cordova) framework. Don’t expect too much theory – it’s a practical guide explaining how RYLC Web App was built, to kickstart your own development. Currently only available in German as paperback and eBook. WebLogic Partner Community For regular information become a member in the WebLogic Partner Community please visit: http://www.oracle.com/partners/goto/wls-emea ( OPN account required). If you need support with your account please contact the Oracle Partner Business Center. BlogTwitterLinkedInMixForumWiki Technorati Tags: adf mobil

    Read the article

  • Good Scoop: The PeopleSoft/IBM Backstory

    - by [email protected]
    By Brian Dayton on April 12, 2010 11:15 AM Sometimes you're searching for something online and you find an unrelated, bonus nugget. Last week I stumbled across an interesting blog post from Chris Heller of a PeopleSoft consulting shop in San Ramon, CA called Grey Sparling. I don't know these guys. But Chris, who apparently used to work on the PeopleTools team, wrote a great article on a pre-acquisition, would-be deal between IBM and PeopleSoft that would have standardized PeopleSoft on IBM technology. The behind-the-scenes perspective is interesting. His commentary on the challenges that the company and PeopleSoft customers would have encountered if the deal had gone through was also interesting: · "No common ownership. It's hard enough to get large groups of people to work together when they work for the same company, but with two separate companies it is much, much harder. Even within Oracle, progress on Fusion applications was slow until Thomas Kurian took over Fusion applications in addition to Fusion middleware." · "No customer buy-in. PeopleSoft customers weren't asking for a conversion to WebSphere, so the fact that doing that could have helped PeopleSoft stay independent wouldn't have meant much to them, especially since the cost of moving to whatever a "PeopleSoft built on WebSphere" would have been significant." · "No executive buy-in. This is related to the previous point, but it's worth calling out separately. If Oracle had walked away and the deal with IBM had gone through, and PeopleSoft customers got put through the wringer as part of WebSphere move, all of the PeopleSoft project teams would be put in the awkward position of explaining to their management why these additional costs and headaches were happening. Essentially they would need to "sell" the partnership internally to their own management team. That's not a fun conversation to have." I'm not surprised that something like this was in the works. But I did find the inside scoop and Heller's perspective on the challenges particularly interesting. Especially the advantages of aligning development of applications and infrastructure development under one roof. Here's a link to the whole blog entry.

    Read the article

  • chat application: pubsubhub vs xmpp

    - by sofia
    I'm unsure on the best stack to build a chat application. Currently I'm thinking of two main options: facebook tornado cons: does not use the main chat protocol xmpp but pubsubhubbub pros: i really like its simplicity for development (webserver + webframework); pubsubhubbub also seems simpler as a protocol than xmpp; and i know python xmpp + bosch, punjab, ejabberd cons: don't know erlang; overall seems a bit harder to develop pros: uses xmpp protocol The chat app will need to have the following: Private messages Public rooms Private rooms Chat history for rooms (not forever, just the last n messages) html embedding url to chat room Both options seem scalable so that's not really my worry (we're thinking of running the app in amazon's ec2 as well). I know there's a project that builds a xmpp server using tornado but it's not ready for production use and our deadline isn't that big. Basically my main worry is ease of development vs somehow regretting later using pubsubhubbub to develop a chat app but I read somewhere that PubSubHubbub might eventually replace XMPP as REST replaced SOAP - so what do you think?

    Read the article

  • chat application: pubsubhubbub vs xmpp

    - by sofia
    I'm unsure on the best stack to build a chat application. Currently I'm thinking of two main options: facebook tornado cons: does not use the main chat protocol xmpp but pubsubhubbub pros: i really like its simplicity for development (webserver + webframework); pubsubhubbub also seems simpler as a protocol than xmpp; and i know python xmpp + bosch, punjab, ejabberd cons: don't know erlang; overall seems a bit harder to develop pros: uses xmpp protocol The chat app will need to have the following: Private messages Public rooms Private rooms Chat history for rooms (not forever, just the last n messages) html embedding url to chat room Both options seem scalable so that's not really my worry (we're thinking of running the app in amazon's ec2 as well). I know there's a project that builds a xmpp server using tornado but it's not ready for production use and our deadline isn't that big. Basically my main worry is ease of development vs somehow regretting later using pubsubhubbub to develop a chat app but I read somewhere that PubSubHubbub might eventually replace XMPP as REST replaced SOAP - so what do you think?

    Read the article

  • Good Scoop: The PeopleSoft/IBM Backstory

    - by Brian Dayton
    Sometimes you're searching for something online and you find an unrelated, bonus nugget. Last week I stumbled across an interesting blog post from Chris Heller of a PeopleSoft consulting shop in San Ramon, CA called Grey Sparling. I don't know these guys. But Chris, who apparently used to work on the PeopleTools team, wrote a great article on a pre-acquisition, would-be deal between IBM and PeopleSoft that would have standardized PeopleSoft on IBM technology. The behind-the-scenes perspective is interesting. His commentary on the challenges that the company and PeopleSoft customers would have encountered if the deal had gone through was also interesting: ·         "No common ownership. It's hard enough to get large groups of people to work together when they work for the same company, but with two separate companies it is much, much harder. Even within Oracle, progress on Fusion applications was slow until Thomas Kurian took over Fusion applications in addition to Fusion middleware." ·         "No customer buy-in. PeopleSoft customers weren't asking for a conversion to WebSphere, so the fact that doing that could have helped PeopleSoft stay independent wouldn't have meant much to them, especially since the cost of moving to whatever a "PeopleSoft built on WebSphere" would have been significant." ·         "No executive buy-in. This is related to the previous point, but it's worth calling out separately. If Oracle had walked away and the deal with IBM had gone through, and PeopleSoft customers got put through the wringer as part of WebSphere move, all of the PeopleSoft project teams would be put in the awkward position of explaining to their management why these additional costs and headaches were happening. Essentially they would need to "sell" the partnership internally to their own management team. That's not a fun conversation to have." I'm not surprised that something like this was in the works. But I did find the inside scoop and Heller's perspective on the challenges particularly interesting. Especially the advantages of aligning development of applications and infrastructure development under one roof. Here's a link to the whole blog entry.  

    Read the article

  • Good Scoop: The PeopleSoft/IBM Backstory

    - by [email protected]
    Sometimes you're searching for something online and you find an unrelated, bonus nugget. Last week I stumbled across an interesting blog post from Chris Heller of a PeopleSoft consulting shop in San Ramon, CA called Grey Sparling. I don't know these guys. But Chris, who apparently used to work on the PeopleTools team, wrote a great article on a pre-acquisition, would-be deal between IBM and PeopleSoft that would have standardized PeopleSoft on IBM technology. The behind-the-scenes perspective is interesting. His commentary on the challenges that the company and PeopleSoft customers would have encountered if the deal had gone through was also interesting: ·         "No common ownership. It's hard enough to get large groups of people to work together when they work for the same company, but with two separate companies it is much, much harder. Even within Oracle, progress on Fusion applications was slow until Thomas Kurian took over Fusion applications in addition to Fusion middleware." ·         "No customer buy-in. PeopleSoft customers weren't asking for a conversion to WebSphere, so the fact that doing that could have helped PeopleSoft stay independent wouldn't have meant much to them, especially since the cost of moving to whatever a "PeopleSoft built on WebSphere" would have been significant." ·         "No executive buy-in. This is related to the previous point, but it's worth calling out separately. If Oracle had walked away and the deal with IBM had gone through, and PeopleSoft customers got put through the wringer as part of WebSphere move, all of the PeopleSoft project teams would be put in the awkward position of explaining to their management why these additional costs and headaches were happening. Essentially they would need to "sell" the partnership internally to their own management team. That's not a fun conversation to have." I'm not surprised that something like this was in the works. But I did find the inside scoop and Heller's perspective on the challenges particularly interesting. Especially the advantages of aligning development of applications and infrastructure development under one roof. Here's a link to the whole blog entry.  

    Read the article

  • Cientos de Directores Financieros se congregaron en el evento “Innovación y Excelencia en la Función Financiera”

    - by Noelia Gomez
    v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} El pasado 24 de Octubre tuvo lugar el evento “Innovación y Excelencia en la Función Financiera” en la Fundación Rafael de Pino, Madrid (que ya anunciamos aquí). APD, en colaboración con Oracle, organizaron esta jornada con el objetivo de analizar el proceso de transformación del Director Financiero en las compañías (aquí puedes ver un estudio sobre ello). Enrique Sanchez de Leon, Director de APD, fue el encargado de abrir la jornada con una calurosa bienvenida a los invitados. Tras él, Fernando Rumbero, Iberia Applications Cluster Leader de Oracle , comenzó dando unas pinceladas sobre los cambios a los que los Directores Financieros deben estar preparados para convertirse en parte de la estrategia de la compañía. Después de que todos los ponentes fueran presentados y se acomodaran en su lugar del escenario de aquella gran sala, Oriol Farré, Presales Director de Oracle, tomó la palabra para profundizar sobre el nuevo rol estratégico del Director Financiero y cómo éste se está convirtiendo cada vez más en el catalizador del cambio dentro de las empresas (¿tú lo eres? aquí hablamos de cómo puedes evaluarlo) Por su parte, Maria Jesús Carrato, Profesora de Dirección Financiera Internacional en el IE y Directora Financiera del Grupo SM mostró su visión sobre cómo serán los Departamentos Financieros del futuro. Después llego el turno de Ramón Arguelaguet, Financial Controller & Reporting Senior Manager de Vodafone, que profundizo en la innovación y la transformación lideradas por los Directores Financieros dentro de las organizaciones. Por último, pero no menos importante, Juan Jesús Donoso, Director Económico de Cruz Roja Española, nos mostro el punto de vista de la gestión de una organización sin ánimo de lucro. Finalmente, en la mesa redonda, cada uno de los integrantes dio su punto de vista sobre el nuevo rol de Director Financiero y los nuevos retos a los que se enfrentan. El broche final de la jornada la puso el coctel para abrir paso a un espacio de networking que sin duda los cientos de Directores Financieros aprovecharon para intercambiar puntos de vista, conocer a nuevos compañeros y reencontrarse con muchos otros. Si estuviste en el evento… ¿qué te pareció? Tal vez no encontraste el momento de plantear alguna cuestión. Ahora puedes hacerlo en los comentarios y se lo trasladaremos a los ponentes. Contact 12.00 Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4 /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin:0cm; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Calibri","sans-serif";}

    Read the article

  • WCF - Increase ReaderQuoatas on REST service

    - by Christo Fur
    I have a WCF REST Service which accepts a JSON string One of the parameters is a large string of numbers This causes the following error - which is visible by tracing and using SVC Trace Viewer There was an error deserializing the object of type CarConfiguration. The maximum string content length quota (8192) has been exceeded while reading XML data. This quota may be increased by changing the MaxStringContentLength property on the XmlDictionaryReaderQuotas object used when creating the XML reader. Now I've read all sorts of articles advising how to rectify this All of them recommend increasing various config settings on the server and client e.g. http://stackoverflow.com/questions/65452/error-serializing-string-in-webservice-call http://bloggingabout.net/blogs/ramon/archive/2008/08/20/wcf-and-large-messages.aspx http://social.msdn.microsoft.com/Forums/en/wcf/thread/f570823a-8581-45ba-8b0b-ab0c7d7fcae1 So my config file looks like this <webHttpBinding> <binding name="webBinding" maxBufferSize="5242880" maxReceivedMessageSize="5242880" > <readerQuotas maxDepth="5242880" maxStringContentLength="5242880" maxArrayLength="5242880" maxBytesPerRead="5242880" maxNameTableCharCount="5242880"/> </binding> </webHttpBinding> ... ... ... <endpoint address="/" binding="webHttpBinding" bindingConfiguration="webBinding" My problem is that I can change this on the server, but there are no WCF config settings on the client as its a REST service and I'm just making a http request using the WebClient object any ideas?

    Read the article

< Previous Page | 1 2 3