How to enable HTC One M8 Verizon to work with GSM and 4G

It took me more than two months, tons of reading and experiments to get my HTC One from Verizon (model HTC6525LVW, android 4.4.2.) to work in Argentina. Hope this helps others like me.

These are the problems I run into, in the next section I describe how I fixed them:
1.- Lack of power saving mode (making batteries run out in less than a day)
2.- Tethering (Mobile Internet Network sharing) not working
3.- No 4G access

This is how I fixed these issues:
1.- Installed JuiceDefender from Play.
You have to give it several days before it will actually produce results.

2.- To enable mobile network sharing:
2.1./ Obtain S-Off by paying u$s25 for Sunshine (download from Play). All free alternatives did nor work for me. If you are not S-Off, all changes are overwritten on restart.
2.2./ Obtain temporary root by installing KingRoot (download http://www.kingroot.net). I had to try several times until I got root access, but it is faster after the first time, and eventuallly I got it.
2.3./ Use RootBrowser (download from Play) to edit the file /system/customize/ACC/default.xml
Replace the 1 with a 0 in the following line

<item type=”integer” name=”TetheringGuard_rule”>1</item></app>

so that it reads

<item type=”integer” name=”TetheringGuard_rule”>0</item></app>

3.- To obtain 4G access
3.1./ Using RootBrowser, edit the file /system/build.prop
3.2./ Modify the property ro.telephony.default_network, set it to 9 (in my setup the property existed twice, I modified both entries).
9 stands for GSM+LTE, which is neither available in the settings menu nor using the Network or 4G Switcher tools.

Also, comment the following line by prefixing it with a #:
telephony.lteOnCdmaDevice=1

and add the following line:
telephony.lteOnGsmDevice=1

The modified lines should look like this:
ro.telephony.default_network=9
#telephony.lteOnCdmaDevice=1
telephony.lteOnGsmDevice=1

Restart and give it some time, when I did this I thought it had not worked until the next day I went out and found I had 4G. It seems I did not get good 4G reception where I was.

3.4./ You might also need to update/add an APN in you Settings > Mobile Data > GSM Options > Access Point Names
You can find the information for your carrier easily, here is one example (in Spanish):
http://nacho.com.ar/2012/11/como-configurar-apn-internet-y-mms-de-personal-argentina/

Note: The Verizon HTC One M8 has 4G Band B4 enabled, so you should not need to do anything special to enable it).

These are some of the sources I used to compile this information, in most cases I am simply putting it together.

http://www.cultofandroid.com/61639/enable-free-wi-fi-tethering-htc-one-m8/

http://www.internauta37.altervista.org/en/patch-fully-enable-gsm-cdma-global-phones-android

My favorite books on agile that are not agile

Yes, these are some of my favorite books on agile, the ones that have changed me most or that I found closest to my heart, and they are not agile. But these are all books on agility, each in its own way.

Some of these had me laughing out loud on the bus or talking very fast to everyone around me, trying to tell them about the ideas I had discovered. They are all worth it, I hope I can spark your interest in them.

Here they are, in chronological order in which I read them:

1- Artful Making, by Rob Austin and Lee Devin

2- The Social Life of information, by John Seely Brown and Paul Duguid

3- Slack, by Tom De Marco

4- The Soul of Design, by Rob Austin and Lee Devin

Enjoy

 

Encuesta de Usabilidad de Prácticas y Procesos

Estamos en Ágiles 2015, la VIII Conferencia Latinoamericana de Metodologías Ágiles 2015 y me gustaría recoger la mirada de los asistentes para mi investigación sobre “Usabilidad de Prácticas y Procesos”.

Por favor completen este Cuestionario

Espero que les resulte interesante, y no dejen de escribirme o dejar comentarios.

Diseño colaborativo: un proceso en dos etapas

Hace unos días mi amigo Juan Gabardini me pidió que le recomendara material sobre Diseño Colaborativo y como muchas veces, ese pedido me puso a pensar y repensar. Me acordé que había algo en nuestro libro “Construcción de software: una mirada ágil”, en el capítulo de Diseño y Arquitectura, pero también como me suele pasar, encontré al revisarlo que en el libro no decíamos exactamente lo que yo quisiera decir ahora. Esto, sumado a la falta de otras referencias inmediatas que me surgieran, me llevó a escribir este post.

El diseño es un proceso creativo que consiste en generar alternativas y luego elegir una de ellas, plasmando esa decisión de alguna manera (esquema, diagrama, dibujo, código, texto, etc.). Esas alternativas surgen tanto a partir de las restricciones (entre ellas los requerimientos) como de la historia personal de los involucrados, como suma de sus experiencias.

El diseño colaborativo se caracteriza principalmente porque durante la primera etapa los participantes reconciben sus ideas a la luz de las ideas de los demás (Lee Devin acuñó el término en su libro Artful Making), creando así nuevas ideas que son potencialmente mucho más interesantes que las ideas originales aportadas por los participantes. Luego de generar esas ideas en forma colectiva, se procede a elegir entre ellas y plasmar esa decisión.

Un aspecto interesante de este proceso es que además de producir mejores ideas, permite también aprovechar el aporte de todos al máximo, no sólo por lo que vale en sí mismo si no por lo que puede despertar en los demás. De alguna manera, esto resuena con el ideal budista de “mente de principiante”, es decir, ser capaz de mirar el mundo con la perspectiva de otro, que sabe menos pero está por eso fresco y sorprendido por las cosas que nos parecen obvias (y por lo tanto no pensamos en desafiar). Un requisito fundamental para este tipo de proceso es que las personas estén dispuestas a “soltar” sus ideas y cambiarlas (este es uno de los aspectos del release, o desapego, otra característica budista 🙂 ).

En otro sentido muy cercano a la agilidad, en el diseño colaborativo la decisión de qué idea seleccionar no es tomada por una jerarquía (el arquitecto o grupo de arquitectura), si no que es tomada en forma conjunta. Existen múltiples dinámicas para esto, como por ejemplo:
* Cada participante vota (cada uno puede tener X votos, donde X es aproximadamente igual a un tercio del total de opciones).
* Buscar consenso (tiene el riesgo de producir parálisis, por eso podemos poner un límite de tiempo, ver el capítulo “Buscando Consentimiento” de Por un Scrum popular, notas para una revolución ágil, de Tobias Mayer y Alan Cyment).
* Rotar un responsable de la decisión (por ejemplo, rotar el rol de quién decide un empate en la votación o cuando no hay consenso luego de transcurrido un cierto período de tiempo).

Un proceso colaborativo exitoso típicamente se caracteriza por:
* No se puede a posteriori identificar de quién fue una idea, porque fue modificada por varios y se transformó tanto que la idea seleccionada no es ninguna de las ideas originales. Esto es algo que descubrí aplicando estas ideas en la realidad y que he visto repetirse hasta formar un patrón. Mi propio acto de intentar identificar la persona que originó la idea es un gesto de apego interesante :-).
* El proceso mismo promueve la autonomía y actúa como motivador para los participantes.
* Requiere condiciones de ambiente seguro para la participación y muchas veces un facilitador para mantener ese espacio.
* Una etapa clara de divergencia (generar ideas libremente sin juzgarlas ni criticarlas) y otra de convergencia (validar esas ideas contra las condiciones objetivas, ajustar aspectos específicos, seleccionar una idea, plasmar esa selección).
* Límites al proceso claros, por ejemplo, duración, objetivos y alcance. En particular, el time-boxing suele servir como límite a la etapa divergente.
* Alguna de las ideas generadas supera en algún aspecto a las soluciones de compromiso típicas o evidentes (esto depende de que los recursos, por ejemplo el tiempo, no sean muy limitados, si lo son tendemos a terminar en soluciones de compromiso).

Cuestiones que dificultan un proceso de diseño colaborativo:
* Egos muy desarrollados.
* Apego a las ideas (propias o de los demás).
* Comunicación violenta (corporal, verbal, etc.) que reduce las oportunidades de ofrecer ideas.
* Tiempo muy limitado (es difícil hacer ambas etapas si el proceso debe durar 10min).
* Jerarquías muy marcadas (ejemplo, nadie quiere proponer ideas que puedan incomodar al gerente presente).
* Actitud crítica durante la etapa inicial (gente que comienza sus frases diciendo “No”, “Pero”, etc., puede disuadir a otros de ofrecer ideas).
* Falta de límites u objetivos claros (por ejemplo, la falta de un tiempo máximo definido a priori puede dejar estancar la conversación sin que se tome una decisión).

Es muy importante diferenciar las dos etapas, la divergente y la convergente, y los modos apropiados a cada una. En la primera el modo es abierto y permisivo, no criticamos ni buscamos menoscabar las ideas, sólo hacerlas crecer y desarrollarse. En la segunda etapa, sí es importante cerrar, descartar ideas inviables, discutir las consecuencias detalladas de cada una, y tomar una decisión. Me ha ocurrido en varias conversaciones en los últimos años que el proceso no le queda claro o le “hace ruido” a la gente cuando se los describo, porque me enfoco estrictamente en la primera etapa (divergente). Mi propio enamoramiento (apego) con la etapa divergente me ha hecho olvidar el foco en la segunda, darlo por descontado, lo que es un error y muchas veces me ha llevado a discutir con mis interlocutores que (con razón) no entienden cómo puede ser efectivo un proceso así. En algún caso, me han dicho cosas como “Pero si el otro está equivocado, no podemos dejar de decírselo”. Claro, eso tiene sentido cuando estamos convergiendo en la decisión, pero no ayuda cuando estamos creando alternativas.

Espero que les resulte interesante, y me gustaría escuchar sus comentarios.

Diego

Implementación de Step Definitions en Cucumber-JVM

Muy bueno el post de Nico Paez sobre organización de pruebas con Cucumber

Blog de NicoPaez

Continuando con los dilemas del uso de cucumber, luego de un par de reuniones con los analistas/testers del proyecto, tomamos algunas decisiones:

• Escribir los steps con las menor cantidad de parámetros posibles
• Agrupar los step definitions en base a conceptos de negocio
• Utilitzar Step definitions con estado (stateful)

A partir de esto, el flujo de trabajo es: los analistas/testers identifican los casos de tests y los expresan como escenarios usando lenguaje Gherkin. Luego usando las anotaciones de Cucumber-JVM yo genero los métodos que implementan los pasos de los escenarios. Estos métodos son los que se conocen como “Step definitions”. Hasta aquí llega la herramienta. La forma en que se implementan los Step Definitions depende de cómo sea la aplicación que se pretende testear. Si quisiéramos testear una aplicación web, posiblemente usariamos el driver de Selenium. En mi caso, tengo que testear un sistema de facturación a través de una interfaz propietaria basada…

View original post 234 more words

Bibliografía sobre Arquitectura de Software

Recojo acá algunas lecturas sobre arquitectura de software que me parecen valiosas:

Clements, Paul, Bachmann, Felix, Bass, Len, Garlan, David, Ivers, James, Little, Reed, Nord, Robert, Stafford, Judith, Documenting Software Architecture: Views and
Beyond, SEI Series in Software Engineering, Addison-Wesley, 2003.

Bass, Len, Clements, Paul, Kazman, Rick, Software Architecture in Practice,
SEI Series in Software Engineering, 1998.

Evans, Eric, Domain-Driven Design, Tackling Complexity in the Heart of Software, Addison-Wesley, 2004

Fowler, Martin, Patterns of Enterprise Application Architecture, Addison-Wesley Professional, 2003.

Gamma, Eric, Helm, Richard, Johnson, Ralf, Vlissides, John, Design Patterns,
Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995.

Garlan, David, Shaw, Mary, “Software Architecture: Perspectives on an
Emerging Discipline”, Prentice Hall, 1996.

Meyer, Bertrand, Object-Oriented Software Construction,
Prentice-Hall, 1985, 2da. Edición 1997.

Artículos

Garland, David, Allen, Robert, Ockerbloom, John, ”Architectural Mismatch, or
Why it’s hard to build systems out of existing parts”, Computer Science
Department, Carnegie Mellon University, Pittsburgh, 1995.

Kruchten, Philippe, “Architectural Blueprints- The “4+1” View Model of
Software Architecture”, IEEE Software 12 (6), 1995.

 

Kruchten, Philippe, “Architectural Blueprints- The “4+1″ View Model of
Software Architecture”, IEEE Software 12 (6), 1995.

Scrum with Abrojos

I had the opportunity a few months ago to facilitate a workshop on Scrum with a wonderful group, the Abrojos Collective. The Abrojos organization from the province of Tucumán in Argentina works along several strategic lines tied around Human Rights and Children Rights, from the point of view of Popular Education. They produce radio programs, facilitate workshops and operate a popular library and a communitiy telecenter in the Raco village, 50km from the capital of Tucumán.

It was an amazing experience for me, in particular because I had never run a scrum training outside the software development community, and both the differences and similarities I found, between the work they do and the work we software developers do, turned out to be fascinating.

We worked mostly around physical activities oriented towards understanding the ways of collaboration and complexity, mixed with some short talks to present the Artful Making and Scrum frameworks. The challenges I expected were:

* The group usually facilitates workshop on communication, human and children’s rights, community radio shows and the like, so I considered they might already be familiar with some of the activities I usually use, so I tried to choose activities they would find new and attractive.

* That the group might not share many terms we take for granted in software development, and some terms we share tend to have slightly different meanings (e.g. goals).

* That the role of the Product Owner, or the presence of the business leader might not appeal to them.

I could not have been more mistaken. Most of my preconceptions where dead wrong, and I imagine now that even what I considered engineering oriented activities like the Pajarraco Rasti/Lego building game would work perfectly (I have since learned that Alan Cyment, Astrid Astiz and Veronica Sack have used the game with non software development teams). The group enjoyed both the discussions and the activities, including some techniques I had to use to keep the workshop in track (for instance, I had to teach them to use the talking stick because they would interrupt each other frequently and some discussions seemed never-ending). It was for me a great opportunity for joined reflection on facilitation, the responsibilities of preparing yourself for each activity and the ways in which we try for valuable results in our group dynamics.

Here is a picture of the beautiful natural setting in which the workshop took place:

I would like to hear of your own experiences, thanks,

Diego

Latest readings

These are my comments on the books I read in my Methods: Deciding what to design course.

Books
More about requirements, by Karl Weigers

This book is a great sum of requirements engineering best practices. It takes an ecumenical look at the subject matter, trying to avoid a specific viewpoint.

Advanced Use Case Modeling

A good compendium of use case modeling techniques, although advanced users might not find many new perspectives or techniques.

The Social Life of Information:

A critique of the value that society places in huge volumes of undigested information, this book is a breath of fresh air for us working with information technology. It endeavors to tear down the myths of the home office, the value of information by itself, process vs. practice and learning.

Contextual Design

Psychology meets system’s engineering. This is an eye opener for engineers because it is focused on describing and understanding the work that people do rather than the systems they use to do it. A great tool to try out when interviewing your future users to decide what to design.

The design of everyday things

Again we have psychology to learn design from, in a very interesting and insightful book that explains why the world of common objects around us is usually designed against rather than for people. Of special interest are the feedback principle and the design for error considerations.

The Mythical Man-Month

An absolute classic, the necessary and precise justification of the complexity that we perceive when we work with software. I think “No Silver Bullet” is specially important for those of us who believe that what we do will remain a complex endeavor and a constant surprise.
Hope this will tempt you to do some reading,

Diego

Ágiles 2009 – Florianópolis

Increíble experiencia es la de estar en la 2da Conferencia Latinoamericana de Metodologías Ágiles 2009. Se respira entusiasmo y figuras legendarias del mundo ágil caminan entre los hombres comunes.
Hay en el aire mil palabras para aprender y pensar cosas nuevas, hay gente con la que conversar a cada paso, y hay charlas de tantos temas interesantes que nunca se llega a todo lo que uno querría hacer.

Termina el primer día, mañana veremos.

Scrum para proyectos que no son de software

Mis comentarios como los recogí durante la charla en el Agile Open La Plata

(Ya hubo una charla con este tenor en el Agile Open Buenos Aires.)

Scrum para proyectos de software con artistas (tal vez ni contestan los mails).

Ariel destaca el encuentro de la mejora de exportar hacia otras disciplinnas
Artful Making: Lo que podemos tomar del arte sobre cómo aprender: Por ejemplo, la repetición. La iteración te permite tomar ritmo, pero no debe ser exacta, hay que aceptar la variedad y aceptarla con gusto, porque permite innovar.

Miedo al error, debe cambiarse la cultura. El programa de 12 pasos de AA inicia con aceptar el problema, y reconocer los errores.

El proceso iterativo puede ser raro para organizaciones que no hacen software.

Ariel cuenta cómo el lenguaje técnico de software, con términos como “validación” resultan muy extrañas fuera del ambiente del software. También pasa con la terminología en inglés o mal traducida.

Ariel destaca los valores humanos en las metodologías ágiles, como aporte desde otras áreas de conocimiento. Ejemplos: Colaboración, Comunicación, Innovación.

Ariel, los ingenieros de software necesitan tener exposición a las artes y otros estímulos. Diego, el desarrollo de un lenguaje rico es necesario para construir software, conceptualizar las ideas básicas.

Etnografía para requerimientos de software, sociólogos trabajando.

Experiencias
Ariel, Open Space en vista en fábricas recuperadas. Tienen problemas porque los mandos medios se fueron y las asambleas no funcionan.

Empresa de Diseño gráfico en los cursos de CSM. Usan sprints y retrospectivas. Los dueños forman parte del equipo, que no termina de ser de pares.
¿Cómo llegaron ahí? Fueron a ofrecer sus servicios a la empresa de diseño y fueron aceptados. También aportaron mucho entusiasmo y facilitaron incluso procesos en forma ad honorem. Están en tratativas con organizaciones piqueteras.

Diego propone la colaboración como una reconcepción de las ideas de cada uno por exponerlas a los demás.

¿Cómo implementar Scrum en el Servicio Penitenciario para hacer software?

Diego, los diseñadores gráficos que no quieren entregar versiones borrador, porque la primera impresión es muy fuerte. Es decir, se pueden tener procesos por incrementos, pero no tanto evolutivos.

Ariel, la diferencia puede estar en la menor complejidad, tal que no requiera incrementos, simplemente iteraciones donde el equipo es el resultado (Diego).

Grupos de 5 ingenieros electrónicos usando modelos iterativos (Juan).

¿Qué llevarles a los artistas? Tal vez el ritmo. Tal vez no sea lo mismo para estudiantes de arte que no tienen experiencia de trabajo en equipo.
Puede disminuir el nivel de estréss y ayudar a autoorganizarse.