Category Archives: Development

When (in my opinion) Not to Use Drupal

By Sebastian Gonzalez – Drupal Developer at Santex

I would like to clarify first off that I love to work with Drupal. I’ve been working with the Drupal platform for about 10 years now, and through all those years of getting frustrated over the same things, I realized something. I noticed that when certain clients or businesses had a previous project in Drupal that was successful, they would want to handle any future projects in the same way, when in reality Drupal may not have been the best tool to use.

In all these years of experience, I came across various projects and had a lot of different experiences – some very rewarding and others not so great. In some of these last projects that I didn’t think were so great, I noticed that something kept repeating. Drupal was being used for any kind of project on the simple premise that “it can do everything.”

If a client needs just any sort of app, we as developers usually say that Drupal is the solution. But what we should is is that Drupal could be the solution. Changing the message from “Drupal can do that” to “Drupal should be able to do that” is fundamental to starting any project off on the right foot.

Drupal is a CMS (Content Management System) that was intended to be a content administrator. Every page in the world has content, and when we talk about ‘content,’ we automatically think that it should be able to be handled administratively. This leads one to automatically think of a CMS like Drupal, WordPress, or Joomla. For me, the important question is what you want to do with the content. Where is this going and what is it going to be used for?

A lot of people view Drupal as a CWMS (Content Workflow Management System), and I agree with this vision. In my opinion, it makes sense to use Drupal when a business’s domain entails a lot of different types of content with multiple users who have different levels of permission. All of these users can alter the state of the content, making it fluctuate through different phases of the workflow where there aren’t annotations, reports, or emails involved.

The reality is that the vast majority of websites built using Drupal should not have used Drupal. This is not because Drupal can’t do the job, but rather because it’s a waste of all its functionalities that end up not getting used. A clear case of this is with classic brochure websites or institutional sites where the content is static and hardly changes over time. There isn’t much interaction between users beyond basic contact forms or a comments section.

Our world is currently dominated by mobile devices. Drupal was able to enter into the competition with its latest version 8, which came out in November 2016. Using and integrating components with the popular framework Symfony provides a robust back-end to facilitate API development. Drupal is jumping onto this trend with something called Headless – an architecture that uses Drupal as the back-end paired with a framework to present the data, which could be AngularJS, React.js, or any other framework.

In summary, I believe Drupal should not be used for:

  • Simple brochure websites
  • Single-purpose apps (like a chat application)
  • Gaming apps

I think Drupal should be used for:

  • News websites with multiple users
  • Multi-user publishing apps
  • Any app or website that includes workflows among people with different roles/permissions
  • A mobile version for Drupal

To conclude, here are 4 more pieces of advice:

  • Choosing one tool or another has to do with understanding the business’s control over the application or website. The more you know about the project, the greater the decision power in choosing which platform to use to meet those needs.
  • Use Drupal from the start and don’t try to switch and start using it for something else when things are not properly in place.
  • Stop saying “Drupal is the solution” and starting saying “Drupal could be the solution!”
  • Always explore alternatives because new technologies are coming out everyday.

Those are my two cents.

 

About the Author – Sebastian Gonzalez is an experienced Drupal Developer at Santex,  passionate about his work.  Sebastian is a strategic team player always willing to contribute and to solve problems.

QA, A Misunderstood Role

By Gabriela Chaves – QA Analyst at Santex

Why it is important to fully understand the role and it’s benefits

keyboard-886462_640

If you have been close to the software development process, chances are that you have experienced working on agile projects where it is common to conduct a small waterfall model in which the QA runs tests on late stages of development or perhaps there’s no QA assigned at all. In my experience, I find that this reveals only a slight notion of what a QA does and the impact his or her work has on an agile project. I believe it’s beneficial to share deeper insight on the responsibilities of this position.

The QA applies an analytical mindset throughout the complete process with this concept in mind:

“Are we building the right product, and, if so, are we building it correctly?”

A person in this role is someone who constantly questions all parts of the development process to ensure the team is producing the desired output. Kenny Cruden indicates this in his article “The QA Role – What Is It Really?” It is also referenced in international quality norms and standards such as ISO 9000 and CMMI dev with the name “Verification and Validation”.

Adding detail to the already known activities, a QA also thoroughly analyzes the product to be developed, and from sprint zero starts suggesting improvements and changes, polishing unclear aspects, detecting possible discrepancies and bugs, and bringing attention to items that may have been overlooked, with the aim of avoiding issues before they come up. Working side by side with Business Analysts and Developers, a QA and his or her team will not only develop an usable product, but they will also deliver one that suits the client’s needs. By constantly keeping in mind the business and the user perspectives, the QA helps build a better, stronger, and more reliable product, resulting in a satisfied customer and a greater appreciation for the company’s work.

There’s an internal benefit as well as Stephanie Dedhar points out in her article “Six irresistible benefits of real quality assurance.”

‘A focus on QA helps to develop a culture of continuous improvement. Colleagues will help each other develop, challenging things and preventing complacency setting in and leading to carelessness. In my experience, high standards are infectious – if one or two members of the team set the right example and pick up even the littlest things, these good habits will spread and you’ll develop a true QA culture.’

From all of this we can infer that the work performed by quality control specialists has a bigger impact than assumed by the people outside the project, providing an increase in quality and helping make the client happy with the end results. It can also be noted that starting the work early as previously described can result in increased client satisfaction and a reduction of rework, in turn reducing the total costs of the project.

About the Author – Gabriela Chaves is an experienced QA Analyst at Santex,  passionate about her work. Great analytical skills and quick learner.

Sources

Kenny Cruden – https://www.thoughtworks.com/insights/blog/qa-role-what-it-really

Stephanie Dedhar – https://stephaniededhar.wordpress.com/2012/01/24/six-benefits-of-real-quality-assurance/

5 WWDC ’16 Announcements Every Software Development Company Needs to Know

By Coleman Miller – iOS Developer at Santex

wwdc16

Apple made a lot of announcements last month in its annual World Wide Developer Conference, and introduced the latest versions of its operating systems and developer tools. Here is a breakdown of the most important announcements that will affect software development companies moving forward.

1. SiriKit

In my opinion, this is the most sought-after functionality developers and clients alike have requested over the years. Well, its finally here. Apple is providing a public API so third parties can develop iOS extensions that trigger in response to Siri. The only drawback is that it is limited to the following categories:

  • Audio or video calling
  • Messaging
  • Payments
  • Searching photos
  • Workouts
  • Ride booking

In addition to these new features, its worth mentioning that Siri already supports automotive control features with CarPlay, and HomeKit has allowed allowed Home Automation with Siri since iOS 8. This new API is going to help usher in a wave of innovation and new categories of mobile apps we haven’t seen before. It will also greatly improve the UX of existing apps like Uber and WhatsApp.

2. Swift 3

Although this should be #1 on this list, I believe Swift will bring more changes to software industry in the long term, but short term, Swift 3.0 is a huge improvement from 2.3. One of the biggest breaking changes is Apple adding “Swift Overlays” to its frameworks (some of which were originally written in Objective-C in the 90s) to make Swift a first-class citizen for iOS development. Another breaking change that will affect every single iOS app (with any Swift code), is the move by Apple to forgo classes in favor of structs and value types in its Foundation framework. This is more than a simple API change, it’s in fact, a huge paradigm change for current Apple Developers and programmers coming from other languages like Java, C#, and JavaScript. C developers should feel at home though. Unlike last year, Apple is letting developers chose between Swift 3.0 and Swift 2.3 for publishing apps to the App Store, so developers can take their time migrating to the new version of Swift.

3. Home App

When HomeKit was announced in iOS 8, it took a while for companies to make their existing IoT products HomeKit-compatible. Fast forward 2 years, and now HomeKit is a first-class citizen of iOS, even shipping a beautiful `Home.app` on your home screen. HomeKit’s goal is the unification of IoT and Home Automation products by adopting an Apple-defined protocol so they can easily talk to each other. This allows you to control the lights in your house via Siri, and setup home automation rules (Apple calls them “Scenes”) similar to what IFTTT does with apps. While Apple has accomplished this goal protocol-wise (by providing both HTTP and Bluetooth variations of its HomeKit Accessory Protocol to encompass all manner of devices), besides the Siri integration, Apple provided no user interface for HomeKit, and on the app side, that experience was fragmented. With the new Home app, centralized home automation is easier than ever, and you won’t need to download the specific third-party apps for each HomeKit accessory you purchase. This should boost HomeKit’s popularity and demand with hardware developers.

4. WatchOS GPU-accelerated Games

WatchOS is in a special category of iOS development due to the lack of native APIs like OpenGL and UIKit. While most attribute the App Store’s success to the proliferation of mobile games, that innovation and boom would have not been possible had the iPhone only allowed Web apps like Steve Jobs originally planned. Due to the issue of battery life, the Apple Watch provides a very limited API for native apps, in fact, its more limited then making an average website. One way Apple wants to lure developers to its WatchOS platform is by allowing them to make OpenGL accelerated 2D and 3D games with its SpriteKit and SceneKit frameworks. Since this is what many developers have asked for since day one, it will promote a boom of WatchOS games, like we see on the iOS and tvOS platforms. One drawback is the fact that those platforms can use OpenGL and natively port their code from Android, to iOS. WatchOS game developers will have to rewrite their rendering code for Apple’s platform.

5. Message and Map Extensions

With the introduction of iOS extensions in iOS 8, Apple has allowed third party apps to embed a part of their app in Apple’s stock apps (e.g. Contacts, Photos) and other third party apps. Now in iOS 10, developer’s can write extensions for the Message and Map stock apps. This will allow users to use apps like Uber and Yelp in the stock `Maps.app` without having to switch between contexts. The Message extensions allow all manner of custom content in the stock iOS messaging app, again, allowing for a new category of mobile apps.

About the AuthorColeman Miller is an experienced iOS Developer at Santex,  passionate about his work.  Coleman is continuously learning and training to investigate new technologies.

What Thread, Main Thread? Part II

By Martín Zangl – Android Developer at Santex

mobile-phones-1

If we are to understand some basic, common behaviors for approaching a simple solution using threads, we know that at some point we have to manage communication and execution order. For that, Android provides us with a bunch of concurrency and communication frameworks that are designed, implemented, and integrated in accordance with many patterns that you can find in POSA books.

Android provides differents tools according to concurrency patterns:

We can resolve many problems with one or more of the following:

  • Using handlers and other threads
  • Asynctasks
  • Loaders
  • IntentServices

Custom Handlers and Threads

As previously stated, there is only one Looper per Thread, but we can also have different handlers post messages and process them.

For example, we could define two threads with two handlers to send messages to each other.

threads1.png

For one instance, what if one of that threads is the Main Thread, we could send update messages to UI widgets and notify something happens in the other thread. Remember that if we are just using a simple pattern like observer pattern and notifying every change directly to the UI won’t work because we are trying to change the state of view object from a thread other than the main thread. In that case we could post the result or intermediate results on the handler registered to the main thread. In other words, we have an Activity, we declare a new Handler, that handler would be associated to the Main Thread – that is, the main looper – so every time we send a message from another thread, the handler will post the message in the message queue, then the looper will process that message sending it to the registered handler. Then we can update some UI widgets.

This is a pretty clean solution, but it becomes very difficult to handle the UI widgets’ lifecycle. That is to say a configuration change happens or the user changes the context often.

The worst scenario is when a configuration change happens, because in that case a new instance of the activity will be created. It would be even worse if we had references for any particular view on those messages; in that case the reference cannot be garbage collected and we’d just be leaking memory.

More in detail, every time that a configuration change happens two new messages are posted to the looper queue, one is CONFIGURATION_CHANGE and the other is RELAUNCH_ACTIVITY and this is what happens after that message is processed:

  1. calls onSaveInstanceState(), onPause(), onDestroy() on the old activity instance.
  2. create a new activity instance.
  3. calls onCreate() and onResume() on that new activity instance.

In the case that we send messages from other threads to the main thread, we have be careful. We cannot predict in which activity instance we are posting those messages.

We could do some speculation and think if any message posted before the orientation change would be handled before onPause() the leaving activity, and if any message posted a after the orientation change will be handled after onResume() he incoming activity.

 What can we do?

Fix the architecture instead of messing it up with handler.post().

Do not hold view or context references.

Remove all messages or callbacks in the activity onPause()

And the last one if you want to get fired use hanlder.postAtFrontQueue() to make sure a message posted before onPause() will be handled before onPause().

Next post we’ll talk about Asynctask, IntentService and Loaders.

About the Author – Martín Zangl is an experienced Android Developer at Santex,  passionate about his work.  Martín is continuously learning and training to investigate new technologies.

Source:
https://corner.squareup.com/2013/12/android-main-thread-2.html
https://www.youtube.com/watch?v=S1Y1Zt3lfeQ&list=PLZ9NgFYEMxp4KSJPUyaQCj7x--NQ6kvcX&index=32

 

What Thread, Main Thread? Part I

By Martín Zangl – Android Developer at Santex

mobile-learning

Public Static Void Main

As we know, every single Java app starts with call to method public static void main(). This is true for Java desktop, JEE servlets, and Android applications.

When Android boots, it uses a simple process called ZygoteInit. Zygote (Wikipedia) is a cell that can divide asexually by mitosis to produce identical offspring. This is a VM Dalvik process that loads the most common classes of the Android SDK on a thread, and then waits. When starting a new Android application, the Android system forks the ZygoteInit process. The thread in the child fork stops waiting and calls ActivityThread.main()

Here is what it’s essentially doing:

public class ActivityThread {

public static void main(String... args) {

Looper.prepare();

Looper.setMainLooper(Looper.myLooper());

Looper.loop();
}
}

Looper? What is a Looper?

Here we can find a particular concurrency pattern called Thread-Specific Storage. This pattern allows multiple threads to use one “logical global” access point to retrieve an object that is local to a thread, without incurring locking overhead on each object access.

articulo

When a Android application starts, it creates a Looper object. A Looper object contains a static ThreadLocal object, a Message Queue, and the Thread reference that created it. In other words, a Looper implements a Thread-specific event loop. Using a Looper is a good way to process messages serially on one Thread.

Looper.prepare(); This operation associates the looper with the current thread and storage it in a static ThreadLocal.
Looper.loops(); will process each message in the queue, and block when the queue is empty.

As previously said, each looper is associated with one thread. To retrieve the Looper associated to the current thread you can use the method Looper.myLooper().

An example of using a Looper with a Thread:

class HandlerThread extends Thread {
Looper looper;
public void run() {
Looper.prepare();
looper = Looper.myLooper();
Looper.loop();
}
}

Handlers is the natural companion to a looper. Looper has a Message queue and Handlers put messages or runnable objects in place and process each of them, i.e. it allows them to send messages to a looper message queue from any thread and handle messages dequeued on the thread associated to that looper.

You can associate many handlers to one looper. The looper delivers the message to one specific handler.

A default Handler constructor associates it with current the thread and its looper. We could define the other Looper if we want in order to post messages to the Message queue of whatever Looper we want.

The looper instanced in the void main method is called Main Looper, part of the Main Thread. This particular thread is in charge of dispatching events to the UI widgets that include the drawing events. All components (other Activities, Services, Broadcast Receivers and Content Providers) that run in the same process are instanced in the Main Thread.

When an application performs intensive work in response to user interactions, this single thread model can yield poor performance. If everything is happening in the Main Thread it will block the whole UI, so no events can be dispatched, including drawing events. That is when a ANR (Application Not Responding) dialog appears. In that case, we just put all the long background operations in another thread, but other problems arise in paradise – only the main thread can process UI widgets. So, we need to somehow handle communication between threads.

Next post we’ll talk about:
Using custom handlers and other threads
Asynctasks
Loaders
IntentServices

About the Author  – Martín Zangl is an experienced Android Developer at Santex,  passionate about his work.  Martín is continuously learning and training to investigate new technologies.

Source:
https://corner.squareup.com/2013/10/android-main-thread-1.html
http://developer.android.com/reference/android/os/Looper.html
http://developer.android.com/guide/components/processes-and-threads.html

7 tips for new Project Managers

IMG_2912

By Johan Tabori – Project Manager at Santex

The project management role has evolved very rapidly over the last two decades. The traditional view of “boss” has morphed into a combination of “facilitator” and “coordinator” which fits better in agile organizations. The following tips may help you to improve your project management skills in today’s increasingly changing business environments:

1. Ensure healthy and friendly work environments.
Fear is the worst incentive to work, therefore, make sure the team work environment is as friendly as it can be, your teammates will trust you and you will be able to delegate responsibilities more adequately. Same works for the client, team dynamics can be affected by how good a relationship with the client is, so don’t be afraid to demand collaboration and mutual respect.

2. Know your team and client.
As a project manager, you need to be a little bit of a psychologist. As you move forward in the project, it’s very important to understand both your team’s and client’s mindsets. This will become very helpful when bringing up sensitive issues or when you need to resolve conflicts.

3. Quickly respond to communications.
Unless you are in a meeting or have an emergency, don’t wait too long to respond an email or call. If you’re not sure about the topic in discussion, don’t be afraid to ask for clarifications. If it requires further investigation, let the sender know and promise you will looking into it and get back to him/her as soon as possible.

4. Review project status with your client periodically.
Weekly follow up meetings is the best way to keep your client and/or stakeholders informed. Make sure you cover key aspects of the project such as current status, scope, milestones, communications and team updates.

5. Involve your team as much as possible in key decisions regarding the project.
In most cases, your team have more technical skills than you do, so instead of imposing any particular technology, architecture or framework, make sure these are agreed within the team.

6. Take the opportunity to learn.
Self centered project managers fail miserably in accomplishing long term goals . Acknowledge your weaknesses and information gaps and learn from every team member and client.

7.  Demonstrate your value as a service provider before asking for more business.
Clients hate when they are presented with prospective new businesses at the beginning of the contract. They want to see you “in action” before they can start thinking about it. Once you have proved you deliver value to their organization, they will come to you and discuss future projects.

 About the Author
Johan Tabori – Johan’s education as an informatics engineer prepared him well to become the project manager that he is today. A natural multi-tasker, he has been leading IT project teams in a variety of vertical markets and applications for more than 10 years.

Extreme programming… once again

By Jose Torres – iOS Software Engineer at Santex

images

Vague or constantly-changing requirements are a fact of life. Instead of ignoring them, we should adapt our processes to reality. Extreme Programming (XP) principles exist to help us safely drive the work of building software. The web is full of information on XP, which can be synthesized as:

> Lightweight, evolving, flexible knowledge to develop software.

The concept of XP comes from the 90s. It bears repeating though, because, unfortunately, many organizations have lost the point. Perhaps they apply technical principles and fail in their flaccid adaptation. Maybe they employ agile processes but little technical practices. Can these discrepancies be balanced? How can we fight back?

Move to an extreme state and embrace its principles. Some organizations resist this shift. One of the best ways to adapt to this change is by running a pilot on a small, internal project.

XP principles state that at least two developers must work in a single workstation. To extend this concept, add one more step after the development sprint organization and consider having the team determine the number of developers who will work together for each user story. On the most critical user stories, place the whole team at a single workstation to discuss and then write production code.

XP principles also dictate a short release cycle for the product. To take this concept further, set up a specific time period during the day (i.e., every three hours) to continually release the product. You could also consider a full integration, if possible. This will help relieve the problems of production integration later, as integration is always happening. As David Farley states “reduce cycle time and the rest falls out.”

Keep in mind that having an active local community can help you to go further. In London, for example, there are multiple extreme programming initiatives like XProlo, eXtreme Tuesday Club, XPDay dedicated to XP practices, where people can join and share knowledge. We should continue creating initiatives and networking to create communities and evolve together.

There are many ways of actively moving forward on integrating extreme principles to software development. As main actors, we are responsible for tracking the efforts of our organizations as they assimilate real XP practices to the next level.

About the Author
Jose is an innovative Software Engineer who specializes in developing iOS applications for both iPhone and iPad. Skilled in creating business applications as well as games, Jose enjoys mentoring colleagues and fellow developers.

How Agile methodologies mitigate cognitive biases that lead projects to failure

By Walter Abrigo, Managing Director at Santex

I want to emphasize in this article how the existence of two cognitive biases (which are almost always present in our daily lives) position agile methodology practices  as one of the most adaptable frameworks for project monitoring and management in general. This is especially true when the context of the given project development is complex, has changing requirements that are poorly defined, and where innovation, competitiveness, flexibility, and productivity all combined are critical to achieving the desired results.  

Cognitive biases

  1. The emotional aspect of our decisions and choices.

  2. The fallacy of planning.

By reviewing each of these biases, we can see how people’s behavior fits better and more consistently with the structure of Agile methodologies.

Our decisions and choices are emotional

The following cases demonstrate how in our everyday decision-making we often forget the Base Rates (or the true distribution of events). Additionally, we strive to make sense of representative stereotypes, we seek causes and explanations, and we have a natural aversion to losing whenever there is something at risk.

First Case: Forgetting the Base Rates (the true distribution of events)

Tom is extremely intelligent, although he lacks true creativity. He needs order and clarity, and prefers systematic organization. He has a strong competitive drive and seems to have little interest and sympathy for others. He does not enjoy dealing with other people. Although he’s self-centered, he has deep moral awareness.

Let’s order the following nine areas of expertise according to the probability that Tom would be a student in any of these fields. We’ll use 1 for the most likely and 9 for the least likely.

  • Business Administration

  • IT

  • Engineering

  • Humanities and Education

  • Law

  • Medicine

  • Physics and Biology

  • Social Sciences and social work

Most will agree that Tom fits well with the stereotypes of smaller groups of students, like IT and engineers, but would fit poorly into larger groups, like humanities and education, social sciences and social work. This is an example of how we substitute the probabilities of the Base Rates for representative stereotypes.  

Second Case: Prejudices based on stereotypes

Linda is thirty-one years old. She’s single, outspoken, and very bright. She majored in Philosophy and when she was a student, she was very concerned about the issues of discrimination and social injustice. She participated in several anti-nuclear protests. Given this information, which of the following scenarios fits best with Linda’s personality?

  1. Linda is a bank teller.

  2. Linda is a bank teller and activist for the feminism movement.

Most will agree that Linda is most suited to the role of “bank teller and feminist.” The stereotypical teller may not be a feminist, so including this detail adds more emphasis to the description. Nonetheless, both feminist tellers and regular tellers share the common fact that they coexist in the world of ‘tellers.’

P(teller)=P(feminist teller) + P(teller not feminist).

Third Case: Seeking causes

Take the gender of six children born one after the other in a hospital. The sequence of boys and girls is random. Each event (birth) is independent of the other, and the number of boys and girls born in the hospital in the last hour has no effect on the gender of the next child. Consider now three possible sequences (M = male, F = female):

  1. MMMFFF

  2. FFFFFF

  3. MFMMFM

Are these sequences equally probable? The intuitive answer is, “Of course not!” but that is false. Because each event is independent and the results M and F are both (approximately) equally likely, all possible sequences for the six births are as likely as any other. Now that we know that this conclusion is true, it seems counterintuitive because only the third sequence appears to be completely random. Our minds are built with associative machinery that continuously seeks causal relationships, and this tendency leads to serious error in our evaluation of sequences that are truly random.

We are hunters of patterns, believers in a coherent world in which regularities (like a sequence of six girls) are not accidentally produced, but rather the effect of a particular cause or someone’s intention.

Fourth Case:  We are willing to risk more when it comes to losses than gains.

Situation 1: Imagine a group of people where each one has $3,000 and you give them a choice between:

  1. Receiving another $1,000, or

  2. Flipping a coin and playing the $1,000 for double or nothing: if they win they’ll receive an additional $2,000, but if they lose they get nothing.

What would you choose?

Situation 2: Imagine a group of people where each one has $5,000 and you give them a choice between:

  1. Giving up $1,000, or

  2. Flipping a coin to play $1,000 for double or nothing:  If they lose, they give up $2,000, but if they win they don’t lose any money.

What would you choose?

Most of us in Situation 1 prefer option 1 and most of us in Situation 2 prefer option 2. The interesting thing here is that the odds of the four options are identical, but differ considerably in our minds. We are more willing to take a risk when it comes to LOSSES and are more reluctant to take a risk when it comes to benefits.

The fallacy of planning

The fallacy of planning in one manifestation of an omnipresent optimistic bias. Almost all humans see the world as less harmful than it really is, our skills better than what they really are, and our goals easier to achieve than they really are. We also tend to exaggerate our ability to predict the future, which exudes optimistic overconfidence.

When we complete a successful project, we assume that it was due to our accurate and detailed planning of controlled variables. We forget the random variables that impacted us positively. We assume the cause of success was within the plan, and we are the performers.  

When we finished a project and it was unsuccessful, we assume that this was due to the presence of external uncontrollable variables, not foreseen from the beginning which affected us negatively. The cause of failure is out of our hands, and we are not the performers.   

Agile methodologies mitigate these biases

Having raised the existence of these two cognitive biases (the emotional side of our decision-making and the fallacy in our planning), we see two aspects of Agile methodologies that make them in the most effective way to mitigate the biases: valuing people and response to change.

By realizing that our decisions are more emotional than they are rational, we place more value on individuals and their interactions than we do tools and processes. This allows us to communicate more empathetically and understand the emotion behind our choices.

Regarding the fallacy of planning, by putting more value on response to change, rather than following a plan, we can better detect the random variables that may arise and impact the results.

In this way, we can realize the importance and value that Agile methodologies have in reducing the noise and deviations that may occur during the development of a project.

Sources

KAHNEMAN, D. (2011) Thinking, Fast and Slow. Debate Editorial.

About the Author Walter Abrigo is a Managing Director at Santex. In addition to his large academic career, he possess market expertise in several organizational processes such as management control, change and strategy, recruiting and staffing as well as performance and engagement.

You can read the spanish version of this article published in “Pulso Social”.

Keys to get a job as a Junior Developer

By Lorenzo Sauchelli – PHP Developer at Santex

What makes a Junior Developer and why companies look for them?

Getting a job when you have no experience can be hard, particularly so in the field of computer science. Usually a company does not look for a ‘Junior Developer’, and not just because they lack the required coding skills to work on a project. The employer has no way of knowing if the would-be employee has the potential to grow into a Senior Developer, have the right work ethics that fit the company, or if they can carry their load on their shoulders without having to constantly ask for help.

Here at Santex we are running a Trainee Program to help junior developers in these areas. There will always be 12 junior developers in the team working on exciting internal projects. The idea is that they get real world experience, evolving into a Full-Stack Developer – basically someone that’s familiar with each layer of development, front-end, back-end, business logic, everything. At the same time, they can work on a product that can be useful for the company.

The skills required for a “Junior” position are completely different than those for a “Senior” one. When we look for Senior developers, we look for people who are not just knowledgeable, but also experienced. Junior Developers, are expected to need a guiding hand.

Another common issue is that companies have much less reliable ways to tell apart the good junior candidates from the not-so-good ones. With senior developers, we can immediately tell if they don’t fit the criteria we’re looking for. With Juniors? It’s another story. We need to discern some key aptitudes that help us detect the great candidates:

  • Life Experience. Since we can’t really measure their work experience, we need to rely on what they tell us about themselves in other areas. Accomplishments that at first glance have little to do with software development can be telltales about how they might act in our industry.
  • Humility. We’re talking about unproven developers here, so arrogant behavior raises a red flag. And not just in a ‘who do they think they are?’ way, it can be a toxic attitude that breaks teams and company culture.
  • Confidence. While this might sound contradictory when put in a list next to ‘humility’, it’s also important that the candidate shows that they’re capable. If they are afraid to speak their mind or unsure about their abilities, chances are they will never grow. Hiring them has little use for a company that’s looking to nurture them into senior developers.
  • Ambition. While a right mix of humility and confidence is necessary, if the desire to learn and grow is not there, then it’s no use. No matter how smart the candidate is, if they don’t want to learn, then they’ll never be capable of expanding their expertise.
  • Logic. Of course, to code, any developer needs a good head on their shoulders. They need to be able to think about a problem and come up with a useful solution to it. This doesn’t mean they need to know everything about the programming language they use, but they need to be able come up with creative solutions themselves. If they can’t even get past a FizzBuzz, then they’re not likely to get past the ‘Junior’ moniker.
  • Communication skills. We don’t look for people that sit all day long coding, keeping to themselves and never talk with anyone around them. We want people who talk, share and explain themselves. Communication builds teams and improves individuals.

Getting hired
Now that we know about some of the key aptitudes companies look for, we can focus on how to show these qualities to an interviewer. Remember, the company is not just looking to find out what you can actually do today, but what you might be able to do in a few months, and years.

  • Talk about what you know. It’s obvious when someone talks about something they have no idea about. People that do this are wasting the interviewers time and their chances of getting hired go down really quick.
  • If you don’t know the answer to a question, say so. Just saying “I don’t know that yet” can do the trick. It can lead to the interviewer asking the candidate to use logic to come up with an answer. This brings to light how well the candidate works under pressure.
  • Learn from as many sources as possible. Blogs, books, and github repositories help the developers to improve themselves. Remember: You don’t need to know all the corners of the programming language you’re going to work with, but you need to show that you care enough that one day you will.
  • Ask questions, and learn to ask “the right questions”. This is key for any project, since a client might want something but not clearly say exactly what. The interviewer might talk about something that assumes some background knowledge to see if the candidate will ask about it.
  • Practice, practice, practice. If you claim to love your craft, you can’t be expected to not know how to write a single line of code. You will get a coding test or two and you’re expected to solve them. Usually it’s nothing major, but if you can’t solve these, then the employer will wonder how you’d ever work in a real-world project.

Nurturing Passion: The road to the Full-Stack Developer
Okay, so you got past the interview and got yourself hired. Good for you! But it’s far from over. Your goal now should be to continue improving yourself and continue showing the qualities that got you hired in the first place.

At Santex we say “WHERE TECHNOLOGY MEETS PASSION” in big bold letters. And to make that a reality we need to nurture this passion, to help the younger developers want to become experienced. The best way to get a Full-Stack Developer is to take steps forward and grow their passion for their craft.

Passion makes perfection. If you don’t love your work, then you won’t care for it, and if you don’t care for it, it will surely suffer for it, making it of a much lower quality. And in the world we live in, quality is a great divider. Clients don’t look for companies where the only thing that’s valued is how cheap the service they give is, they look for quality – even if they don’t know they want it.

So, to get to that much requested quality clients look for, we need skilled workers. Not just skilled workers, actually, but skilled workers that love their work. People that when making a commit, feel good with themselves for a job well done.

Before in this article, I mentioned the Santex Trainee Program and for good reason. It’s a moralizing idea that helps instill this much needed passion into people. Developers don’t love what they do just because they liked writing little programs when they were kids. Managers need to trust the developers and nurture their passion by creating a great workplace. They also need to identify when someone isn’t happy with what they’re doing. This program aims to help not just the new hires get involved in the field and grow them into Full-Stack Developers, but also help Team Leaders into being actual leaders, and create an idea of team that in turn, helps future hires land on softer ground and grow much quicker.

About the Author – Lorenzo is a passionate, experienced PHP developer who is always in search of new challenges. As a high-skilled developer for Santex, he is always looking for new ways of contributing.

How to install Magento2: Create a development environment for Magento 2

By Miguel Balparda – Magento Developer at Santex

This post it’s meant to give an idea of how to create a development environment for Magento Beta 2 dev.

This post will NOT attempt to explain the requirements to use Magento 2, it is only a guide to install Magento2 dev Beta and begin to understand the new directory structure and modules. Remember that this version is not ready for production.

The time required for a complete installation is between 1 and 2 hours depending on the internet connection available.

The minimum requirements were updated between versions 1 and 2 and you may find that a server where 1 runs might not be suitable for Magento 2 without modifying versions of the server software (MySQL, Apache, PHP).

We will use a virtual machine to preinstall all the necessary components to ensure compatibility with Magento 2 without modifying the components of the real or host machine.

93% of this guide will happen in the console without making differences between operating systems.

First step is to clone the VM with

git clone https://github.com/rgranadino/mage2_vagrant.git

Then we enter the directory with

cd mage2_vagrant

to run

git submodule update --init

Magento2, Magento2 sample data and the required libs like composer are listed as submodules in the .gitmodules file.

Once we have all the dependencies installed within the same directory we run

vagrant up

to initialize and provision the VM. We deduct vagrant is installed. If not then enter https://www.vagrantup.com/.

The process is long and without user intervention. This VM is provisioned with puppet. You may find puppet manifest at Manifests/mage.pp. Once complete we must add to the hosts file of the real machine the line

192.168.56.10 mage2.dev

to tell our PC to resolve the domain mage2.dev to the IP of the virtual machine.

Once the whole process is finished we can proceed to the installation of Magento2 entering http: //mage2.dev/ or from the VM.

Personally I chose the installation via command line using

reinstall -s

from the virtual machine to install Magento with Sample data included.

In case of choosing the installation via web you need access the VM with

vagrant ssh

and run

cd /vagrant/data/magento2

composer install

to install the required packages via composer.

To read more about the installation and find all the necessary information and material visit Damian Culotta’s official website (Spanish) or visit http://magenticians.com/installing-magento-2-composer (English).

After the installation, your freshly installed Magento2 will be available at http: //mage2.dev/ and the admin will be at http://mage2.dev/admin

Dashboard access
User: admin
Password: p4ssw0rd

Some images

homepage-m2.png

category-m2.png

category-m2.png

pp-m2.png

Admin Dashboard

admin_m2.png

If you use the web interface to install, these are the accesses to the database:

Host: 127.0.0.1
User: root
Pass: mage2
DB name: mage2

About the Author – Miguel Balparda has been developing Magento for almost five years. During this time, he has witnessed the exponential growth the platform has undergone; today it is one of the largest and most popular online stores in the world. There is a great deal of documentation and resources available for both merchants and developers. It is best to start by scanning the official Magento website, where you can find resources to get in touch with the application, as well as free extensions to learn the structure of modules. Miguel can be contacted at communication@santexgroup.com