Some questions and answers "About me!"

I got those questions from a recruiter and I thought it is Ok to share them as a kind of about me!:

1. What position are you looking for? Android Pervasive Engineer with great capacity of Technology Evangelism 
2. Do you have any experience working in a Scrum environment?
   1. If yes, what was your role? Developer among Development Team
   2. What did you like about the process? Adapting to changes responsively and actively. Continous communication with frequent updates.
3. What is your opinion on CI? Continous Integration is an essential building block in Software Development. Whenever you develop a feature, you are pretty sure that it will work seamlessly with other parts of software. if used properly, gives confidence about the product and its quality.
4. What is QA for you and who is responsible for it? Quality Assurance is a proactive approach to tell this app would not crash. Every one working on the app is responsible for the quality of the app besides the QA team.
5. What does Software Architecture mean to you? How do you ensure you have a maintainable and extensible code base? Building blocks interacting with each other and if you want to scale, you need architecture.  By following Best Practices, Design Patterns, Separating Concerns, Readable Naming Convention and surely Unit Testing.
    
6. How big were the teams you worked in? And what is the ideal team size you feel comfortable with? as Android mobile development team 2-4 people. And it depends on the context 2 to 4 is nice with capacity of Pair Programming. 
7. What is your experience in terms of mobile? I started with the early version of Android 1.1. I keep on track with latest trends in Android development as I am still eager to learn. I conduct presentations, workshops and participate in hackathons whenever possible besides I consider myself as a Mobile Computing Evangelist. 

Configure Android Studio for UnitTesting with legacy structure

So you want to to use unit testing with Android Studio and you have an old code base that does not follow the standard folder structure of Android Studio.

- You need to create test/java folders in the module you want to test.
-- Tip: use external file explorer (e.g. Mac Finder) to do so outside Android.
- Add this to you module dependencies at build.gradle:
-- compile 'junit:junit:4.12'

-- Add Junit to the classPath

-- Start Testing!

Working with Legacy Code

As I am trying to find my way to a better quality well structured code, I am in my journey reading "Working Effectively with Legacy Code" by Michael Feathers.

I found the following strategy interesting:
"The general legacy management strategy is:
1. Identify change points
2. Find an inflection point
3. Cover the inflection point
 a. Break external dependencies
 b. Break internal dependencies
 c. Write tests
4. Make changes
5. Refactor the covered code."

Dependencies Report in Android

So I learnt a nice feature through the Android Summit, How to generate dependencies report for certain module in your app:

-Gradle plugin -> your module -> help -> dependecies
- It will suffer saying no configurations
- Go to  Edit configurations -> tasks -> put your module you need to analyze e.g. ":app:dependencies"
- Build and run again, you would get sth like that:
+--- com.android.support:multidex:1.0.1
+--- project :volley
+--- com.squareup.picasso:picasso:2.5.2
+--- com.beaconinside:beaconinside-sdk-basic-1.2.2:
+--- com.android.support:support-v4:21.0.0 -> 23.0.1
|    \--- com.android.support:support-annotations:23.0.1
+--- com.android.support:appcompat-v7:21.0.0
|    \--- com.android.support:support-v4:21.0.0 -> 23.0.1 (*)
+--- com.google.android.gms:play-services-analytics:7.5.0
|    \--- com.google.android.gms:play-services-base:7.5.0
|         \--- com.android.support:support-v4:22.0.0 -> 23.0.1 (*)
+--- com.google.android.gms:play-services-gcm:7.5.0
|    \--- com.google.android.gms:play-services-base:7.5.0 (*)
+--- com.amazonaws:aws-android-sdk-core:2.+ -> 2.2.9
|    \--- com.google.code.gson:gson:2.2.4 -> 2.3.1
+--- com.amazonaws:aws-android-sdk-sns:2.+ -> 2.2.9
|    +--- com.amazonaws:aws-android-sdk-core:2.2.9 (*)
|    \--- com.amazonaws:aws-android-sdk-sqs:2.2.9
|         \--- com.amazonaws:aws-android-sdk-core:2.2.9 (*)
+--- com.readystatesoftware.systembartint:systembartint:1.0.3
+--- com.sensorberg.sdk:android-sdk-bootstrapper:2.0.0
|    \--- com.sensorberg.sdk:android-sdk:1.0.0 -> 1.0.4
|         +--- com.sensorberg.android:okvolley:1.1.4
|         |    +--- com.squareup.okhttp:okhttp-urlconnection:2.2.0
|         |    |    \--- com.squareup.okhttp:okhttp:2.2.0
|         |    |         \--- com.squareup.okio:okio:1.2.0
|         |    +--- com.google.code.gson:gson:2.3.1
|         |    +--- com.squareup.okhttp:okhttp:2.2.0 (*)
|         |    \--- com.sensorberg.android:volley:1.2.4
|         +--- io.realm:realm-android:0.79.1
|         +--- net.danlew:android.joda:2.7.2
|         |    \--- joda-time:joda-time:2.7
|         +--- com.sensorberg.android:networkstate:1.0.0
|         \--- com.sensorberg.android:volley:1.2.4
+--- com.sensorberg.sdk:android-sdk:1.0.4 (*)
+--- org.igniterealtime.smack:smack-bosh:4.1.5
|    +--- org.igniterealtime.smack:smack-core:4.1.5

Happy analyzing! :)

Reactive Programming

- Why Rx:
abstracting away concerns about things like low-level threading, synchronization, thread-safety, concurrent data structures, and non-blocking I/O. Which makes your code more readable and bug-prone.


The key is stream... Everything is stream of events "Variables, User inputs, Data structures,...".
- A stream can be an input for another stream
- A stream can be filtered, combined or mapped to other values...
- A stream is immutable.
- Subscribe to a stream and get the value from onNext; finish at onCompleted; handle error at onError.
- A stream is called observable.

It is all about Feedback: Incremental Iterative Development

The following excerpt from "Growing object-oriented software guided by tests" is inspiring in how to Software Projects should work...

"The sooner we can get feedback about any aspect of the project, the better. Many teams in large organizations can release every few weeks. Some teams re- lease every few days, or even hours, which gives them an order of magnitude increase in opportunities to receive and respond to feedback from real users.
Incremental and Iterative Development
In a project organized as a set of nested feedback loops, development is incremental and iterative.
Incremental development builds a system feature by feature, instead of building all the layers and components and integrating them at the end. Each feature is implemented as an end-to-end “slice” through all the relevant parts of the system. The system is always integrated and ready for deployment.
Iterative development progressively refines the implementation of features in response to feedback until they are good enough."

Effective Permissions

I conducted a presentation about how to use Android Permissions effectively before and after M release at GDG Android Meetup: GDG Android Meetup

Here is the link for slides: here