Category Archives: Full Stack Development

A Quick Guide to Loading Javascript Faster

how to load javascriptJavaScript is one of the most expensive parts of your website or app. Most mobile and desktop sites run using JavaScript, and they often group all of their JS code into a single package. However, loading all of the code at once can delay interactivity and increase loading times, especially when JavaScript is used on mobile devices. This means that your website or app loads slower and that your users often need to wait a while before they can use your site or app.

Unnecessary JavaScript code can affect your customers’ user experience and may even dissuade them from visiting your website or using your app altogether. This is especially true for users who have mobile devices with slower processors or customers who are using a slower network connection.

JavaScript Processing Times: How Long are Your Users Really Waiting?

According to a Net Magazine article published in July 2018, JavaScript processing times more than sextuple between high-end devices and smartphones with “average” capabilities. When loading, a typical smartphone (the Moto G4) loaded the site nine seconds slower than the iPhone 8, and an inexpensive smartphone needed 32 seconds more to load the website compared to the same iPhone. Unsurprisingly, a desktop and laptop with a Core i7 processor loaded the site the fastest of all. However, in today’s day and age the mobile user experience cannot be dismissed. According to the Pew Research Center, over 77% of all U.S. adults own a smartphone, and one-in-five are smartphone-only internet users.

Given the rapid adoption of mobile technology, and the plentitude of mobile apps and websites available to users, the mobile user experience is of the utmost importance in today’s marketplace. Even if your target audience is expected to own high-end devices, the phones may not always be used in an optimal environment. Site loading times are also affected by the users’ data coverage or the strength of their current network, which is often lacking in a busy work environment or a public WiFi zone.

Fortunately, learning how to load JavaScript faster is as easy as reading this article. Here are some tips to lessen your JavaScript burden and enhance your customers’ user experience.

Code Splitting

Many modern apps and websites group their JavaScript code into one enormous bundle. Code splitting provides an alternative by dividing the code into smaller sections. Only the essential code is loaded up front, which lessens the time needed to load the page. The rest of the code is loaded on an as-needed basis.

If your app employs a heavy use of frameworks and libraries, code splitting will almost certainly improve the quality of your customers’ user experience.

Tree Shaking

While code splitting puts JavaScript code into manageable sections, it does not address code that is never used. Young apps tend to use most of their JavaScript, but as the app ages, more code is added without removing the sections that are no longer needed.

Tree shaking, or the elimination of dead code, addresses this issue by pulling in certain parts of ES6 modules. If some of your JavaScript libraries do not respond to tree shaking, check to see if their methods are exported using ES6 syntax. Whether your website or app will greatly benefit from tree shaking depends on its particular dependencies and architecture. In any case, it’s worthwhile to eliminate any dead code that you can.

JavaScript Measurement and Optimization

Several tools are available to help you measure, monitor, and optimize the JavaScript code on any given page. Lighthouse, part of the Chrome Developer toolbox, offers an in-depth analysis to improve optimization. It can also bring attention to code that may need a lot of time to parse or compile, thereby delaying interactivity. This audit can advise you to split up the code or do less work.

Code Coverage, another part of the Chrome Developer set, can uncover unused JavaScript and CSS in your code by displaying how much code was executed versus how much was loaded. With this knowledge, you can focus on the code that your users need.

Sending Less JavaScript with Performance Budgets

Performance budgets for your website provide clear, measurable figures to keep everyone accountable to the goals for the website or app. Mobile sites should aim for a JS budget of no more than 170KB compressed, which equals approximately 0.7MB of uncompressed code. By working within the budget’s constraints, the site’s performance becomes a constant consideration instead of an afterthought to be addressed down the line.

These budgets can be defined in three ways: milestone timings, which are created in accordance with the user experience on the page; quality-based metrics, which are based on the browser experience using raw figures; and rule-based metrics, which are scores formulated by other tools (e.g., Lighthouse).

Users have a multitude of websites, apps, and companies vying for their attention. A slow-loading site not only affects the user experience on mobile sites, but it can also result in lost leads, conversions, and purchases.

If your site uses a lot of unnecessary code, Santex consulting can re-configure your JavaScript. Our specialized knowledge comes from years of experience in working with numerous platforms, websites and apps. This allows us to attend to your project’s needs, wants, and constraints in an optimal way.Download Ebook Software Development

The Top 7 Most Popular JavaScript Frameworks Used in 2018

popular javascript frameworksJavaScript is constantly changing, and 2018 has been no different. Although certain aspects of the JavaScript community remain constant, such as the open-source run-time environment of Node.js, numerous frameworks frequently enter the scene. With dozens of frameworks to choose from, it can be challenging to find the best platform for your project. Looking at the most popular JavaScript frameworks can help you figure out what framework may be best for your application, project, or development team.

Here are some of the most popular JavaScript frameworks of 2018.


React, which is developed and maintained by Facebook, has been a major influencer for most popular JavaScript frameworks used today. Given its origins and massive community, it has a stability not seen in many of the newer frameworks on the market. As React was created with two-way data binding in mind, it reduces the need to execute frequent DOM operations. Not only can React Native provide a smooth mobile experience alongside your React application for the web, but the use of JSX may help your project to be more SEO-friendly than other JavaScript frameworks.

A possible, although seemingly minor, concern is Facebook’s ability to eventually stop updates or to change the licensing. However, this has not stopped React from turning into one of the most popular JavaScript frameworks of the year.

Unlike Angular (see below), React is still the most popular JavaScript framework, with the most downloads across the three years that data has been tracked. Not only that, React just keeps getting better with age and it promises to be at its current best in 2019.


Known as a framework for “ambitious” developers, Ember is known for its transparency, flexibility, and ability to create complex client-side applications. For developers who are willing to abide by the platform’s rigid best practices, its simplicity and flow of functionality make it easy to get an application up and running quickly. The “ember-cli” command line tool package adds several useful tools to assist developers. The Ember Inspector allows for easy inspection of Ember objects in the browser while developing and debugging problems.

Angular 2

Angular 2, which is developed and maintained by Google, is currently the most popular JavaScript framework on the market. It is often used to develop front-end applications that are large, feature-filled platforms with immense data needs. Unlike React, Angular 2 uses one-way data binding to facilitate DOM operations, which helps developers increase the performance of single-page applications. With several years of development, a predecessor, and the power of Google behind it, this framework has a list of useful features (e.g., dependency injection, forms, templates) and will continue to improve with time.


JavaScript Frameworks React NodeJsUnlike other JavaScript frameworks, Meteor is full-stack and can be used to develop both the  front-end and back-end sections of a project. Both server-side and client-side coding, such as databases and UI, can be addressed with just one framework. It has numerous ready-to-use “smart packages” and also allows the generation of custom packages, providing value for both new developers and seasoned experts. Meteor has one of the most dedicated and engaged communities among the JavaScript frameworks, which comes in handy for support in popular forums and the development and maintenance of packages for public use.


Aurelia is a modern framework that is designed to be practical. As it’s composed of smaller modules, developers can either work with the entire framework or choose separate sections. Aurelia also supports ES5, ES 2015, ES 2016 and TypeScript, giving it the flexibility to be used alongside various JavaScript development situations.


Mithril is one of the leaner frameworks on our list, designed to get a project developed and running with ease. With a compressed library size of 7.8 kb and straightforward documentation, Mithril is a pragmatic choice for developers who want a program that can deal with much of the work that typical JavaScript frameworks handle without the fuss. Although lean, the framework is updated constantly.


Vue has a simpler learning curve when compared to the larger, more complex frameworks. Its small size makes it easy to incorporate into other languages or applications, and its documentation is accessible to both new developers and veterans. Vue also uses an HTML-based templating syntax, so components can be written quickly and simply.

Choosing the right JavaScript framework depends on a variety of factors, and the list of possible choices changes every year. At Santex, we have expertise in a variety of JavaScript frameworks, programs, and environments, such as React and Node. We provide this expertise as part of our custom web development services to create the optimal project for your company. We are strongly committed to providing top quality web development services, and we incorporate our values of integrity, collaboration, service, and leadership with our technical expertise to meet your specialized software needs.

software outsourcing practices agile methodology

Git Basics: Pull Requests

By Agustin Aliaga – Developer at Santex

Git Pull Requests workflowGit is a powerful version control system designed to make software development collaboration easy. It can be used for personal (single contributor) repositories, but it really stands out in projects where multiple developers modify the same codebase every day. Multiple branching models can be adopted. However, in most cases, a Pull Request (PR) will be created when a bug fix or a new feature is ready to be merged into the main branch. The PR itself is an attempt to merge specific changes from one branch to another. Let’s explore the Pull Request workflow in detail.

PR Creation

Whenever a PR is created, the following best practices should be taken into consideration:

  • Add a helpful description to the PR that answers the following questions: What is the requirement or bug? Is there a link to the issue (e.g. on JIRA)? How does your code fix it? Is there anything else the reviewer should take into consideration?
  • Make small, consistent, and logical PRs: We want our PR to be merged as soon as possible. Imagine how hard it would be to review hundreds of file changes at the same time. If this happens, it is likely the reviewer won’t have, or take, the time to do it properly. Do your best to keep it simple and concise.
  • Make sure the PR’s metadata has been set. For example, this can be done by assigning the reviewer (to trigger a notification), setting the assignees, or adding a label (if needed), etc.
  • Configuring the repo’s branching security settings to keep developers away from self-merging their PRs or pushing to a shared base branch. To avoid this, I recommend enforcing Github’s branching security settings. When a large team of developers are collaborating on the same repo, there is a good chance of accidents happening. A single mis-click in a “merge” button can cause terrible headaches. Protecting important branches is something I’d advise most of the time.
  • Avoid submissions that include unresolved conflicts. Fixing those conflicts shouldn’t be a reviewer’s responsibility. PR creators should dedicate time to solving them, either by using Github’s conflict resolution tool (when it’s simple enough) or by using your favorite diff tool locally. You can achieve this by pulling the base branch and merging it into your feature branch. After you’ve pushed it to the remote repo, the PR will automatically update.

Automated tests

If a Continuous Integration system (such as Jenkins, Travis, or CircleCI) is set up, a bunch of hooks can be configured to run unit tests on PR creation. This will allow the team to detect and catch bugs rapidly, as well as prevent conflictive code from being merged. This is a long topic that requires its own blog post, so I’ll just move on to the following stages.

Code Review

After everything related to the creation of the PR is dealt with and the CI tests have been passed, it is time for a code review. Projects tend to have tight deadlines, which can sometimes make code reviews seem like a waste of time to other team members or external agents. Ironically, code revisions can actually help increase productivity and reduce reworks because we avoid bad practices in our code and share knowledge between contributors.

Some benefits of implementing code reviews are:

  • Less experienced developers get to learn from their mistakes.
  • Experienced developers can consolidate their knowledge as they teach others.
  • A high-quality codebase is ensured.

Humility: a soft skill that matters

Sometimes, as work starts to accumulate and things get tense,  engineers have a tendency to become less aware of their attitude toward their peers. It is always important to avoid egocentric behavior, listen to our co-workers, and moderate our communication when reviewing other peoples’ work. If we write a PR review in a disrespectful/arrogant manner, we could be damaging the teams’ confidence and the work environment.

The “reviewer” role

Ideally, teams should implement peer reviews. This means that anyone who has the required experience and skills should review others’ code. In practice, collaborators regularly have different levels of experience in both the technology used for the project and the codebase itself, including its set-up, architecture, code styling, deployment, etc. In this case, experienced developers should be conducting the reviews and newer team members should be included as they progressively get more comfortable with the project.

Merging the PR

After the PR is approved, it’s time to merge it. We have a couple of options for doing so. Let’s explore them:

  • Create a Merge Commit (default): This option will merge all the commits from the feature branch, plus a new merge commit. This is the safest way to perform the merge, since it is a “non-destructive” operation. The downside of using this option is that, since it creates a merge commit by tying together the history of both branches, it pollutes your history tree with multiple “irrelevant commits.”
  • Squash and Merge: This option will “squash” all the commits into a single commit. If the PR includes a lot of commits, this would be the most practical way to approach a squash and merge. It will make your history tree much cleaner and easier to read in your base branch. However, you will lose granularity due to the bigger size of the resulting commit.
  • Rebase and Merge: The “rebase” operation is another way to combine commits from two different branches. This will put your feature branch commits on top of your base branch’s latest commit, effectively rewriting the commit history. After this, it will perform a fast-forward merge, making it look like all the work was done on the base branch. This is extremely dangerous when the rewritten branch is public and shared with other team members. Generally, the rule of thumb is to keep rebasing operations for private-only branches.



When Not to Use Drupal

By Sebastian Gonzalez – Drupal Developer at Santex

 Drupal website or project: when not to use the tool.

First off, I would like to clarify 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, depending on the project.

In all these years of experience, I have come across various projects and had a lot of different experiences, some that were very rewarding and others that were less rewarding. In some of the more recent, less successful projects, I noticed that something kept repeating itself. Drupal was being used for a variety of projects on the premise that “it can do everything.”

If a client needs to create any sort of app, developers usually say that Drupal is the solution. But what we should say 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’ domain entails a lot of different types of content with multiple users who have different permission levels. 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 the 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, 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 into this trend with something called Headless. Headless is 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 four more pieces of advice:

  • Choosing one tool over another has to do with understanding the business’ control over the application or website. The more you know about the project, the greater the decision making power in choosing which platform to use to meet those needs.
  • Use Drupal from the start. 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.



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.

Installing and protecting WordPress from CLI and .htaccess

By Martín Navarro – Quality Assurance at Santex

 Installing wordpress and protecting this CMS from CLI and .HTACCESS

Installing WordPress has never been as easy as it is in the most recent iterations of the program. The first step is as easy as copying all the files over FTP from the CMS to our hosting. The second step involves accessing our site from its URL to start the installation process. Sometimes if we have SSH access to our server we can download and unzip WordPress files directly to our website directory without needing an FTP client, we just need a shell from Linux, OS X or Windows with Putty and to use the following commands.

First, we need to navigate to the root folder of our website. Depending on your hosting and server configuration, that may be different from the following example:

cd /home/your_website/public_html

Now that we are already positioned in our website root directory, we can proceed with downloading the latest WordPress installation files:


The download will start, and be blazing fast since we are using our hosting internet connection.

Now, we can unzip all the WordPress files:


After doing this, we are going to create a new folder in our website root called “wordpress.” We need all the files inside of it, located in our website root folder (only if we are going to host just one WP installation).

cp -rf ./wordpress/* ./

With that command, we are moving all the files inside the “wordpress” folder to our website root folder.

And that’s all! Now we just need to point our browser to our domain and start the configuration of our new WordPress site.

Once the installation and configuration of our new website are done, we need to secure it. One of the easiest ways to do this is by using the .htaccess file (Hypertext Access) within that file. We can override some features of our web server. By using the right commands, we can defend our website from spammers, hackers and other types of attackers.

After enabling the “Permalinks” functionality of WordPress a .htaccess file is created in the root folder of our website and indicates to our web server how the URLs for our posts are going to be created.

Let’s start by protecting our wp-config.php, .htaccess files. These files contain very sensitive information and MUST be protected from attackers. It contains information on the database we are using, such as usernames, passwords, and other configuration parameters.

This is the parameter we must add between the lines “#BEGIN of WordPress” and “#END of WordPress”

<files wp-config.php> order allow,deny deny from all </files>

<Files .htaccess> order allow,deny deny from all </Files>

No one, not even ourselves, will be able to access that file. However, in our case we will still be able to access it via SSH, SCP, FTP.

Let’s disable the directory listing. By doing this we are going to hide our folder structure. This is a good measure to take because it makes the attacker’s first intentions very difficult.

Options All -Indexes

Protecting our images from Hot Linking: This is a technique where other users are able to steal our bandwidth by using our images directly from their URLs onto their own websites. This is good for the bandwidth thief but not for us since all of the images on their website are going to be loaded from OUR web server.

Add the following lines to your .htaccess file.

RewriteEngine On RewriteCond %{HTTP_REFERER} !^$ RewriteCond %{HTTP_REFERER} !^http://(www\.)?*$ [NC] RewriteRule \.(gif|jpg)$ [R,L]

With these lines, the attacker will be able to use the URL but the image displayed is not going to be the right one. Instead, it will be a warning image that we created specifically for these purposes.

These lines and practices are just a few but are among the most important ones to follow right after the installation of our website. They should still be followed, even if you’re using an older version of WordPress.

About the Author: Martin Navarro is a detailed Quality Assurance professional with full system development lifecycle experience, including designing, developing and implementing test plans, test cases and test processes. Martin is a strategic team player always willing to contribute and to solve problems.

Extreme programming… once again

By Jose Torres – iOS Software Engineer at Santex

Extreme Programming principles help us safely drive the work of building software.

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 first came about in the 1990s. 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 in the way of 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 of 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 that there be 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, and XPDay, all of which are 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 when integrating extreme principles in software development. As main actors, we are responsible for tracking the efforts of our organizations as they assimilate and take 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.

Keys to get a job as a Junior Developer

By Lorenzo Sauchelli – PHP Developer at Santex

What makes a good junior developer and why do companies look for them?

Getting a job when you have no experience can be hard. Nowhere is this more true than in the field of computer science. Usually, a company does not look for a junior Developer. This is not just because they lack the required coding skills needed to work on a project. The employer has no way of knowing if the potential employee has the abilities required to grow into a senior developer, whether or not they have the right work ethics to fit in at the company, or if they can carry their load on their shoulders without constantly having to ask for help.

Here at Santex, we have a created a training program to help junior developers excel in these areas. There will always be 12 junior developers on the team working on exciting internal projects. The idea is that they will get real world experience, evolving into Full-Stack Developers, basically someone who is familiar with each layer of development, from front-end to back-end, business logic, and everything in between. 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 required 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, especially in the beginning.

Another common issue is that companies have much less reliable ways to separate the good junior candidates from the not-so-good ones. With senior developers, we can immediately tell whether or not they fit the criteria we’re looking for. With juniors developers, 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 telling 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?” kind of way. It can also be a toxic attitude that breaks teams and company culture.
  • Confidence. While this might sound contradictory when put on 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. They are of little use to a company that’s looking to nurture them into senior developers.
  • Ambition. While the right mix of humility and confidence is necessary, if the desire to learn and grow is not there, then it doesn’t matter how much humility and confidence they have. 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 be successful at coding, 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 talking with anyone around them. We want people who talk, share, and are willing and able to 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 a few months, or years, down the line.

  • Talk about what you know. It’s obvious when someone talks about something they have no idea about. People who do this are wasting the interviewer’s time and their chances of getting hired decrease quickly.
  • If you don’t know the answer to a question, say so. Even saying “I don’t know that yet” can do the trick. It can lead the interviewer to ask 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 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 to learn as much as possible.
  • Ask questions, and learn to ask “the right questions.” This is key for any project, since a client might want something but not be able to articulate exactly what they’re looking for. 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 have to take 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 on a real-world project.

Nurturing Passion: The road to the Full-Stack Developer
Okay, so you got past the interview and were 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 who want to become experienced. The best way to become a Full-Stack Developer is to take steps forward to grow a passion for the 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 from that lack of caring, 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 that much requested quality clients look for, we need skilled workers. Not just skilled workers, actually, but skilled workers who love their work. People who, when making a commitment, feel good about a job well done.

Earlier 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 to help Team Leaders become actual leaders, and create an idea of a team that, in turn, helps future hires land on softer ground and grow much more quickly.

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 is meant to give you an idea of how to create a development environment for Magento Beta 2 dev.

This post will NOT attempt to explain the requirements necessary 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 one and two hours depending on the speed of the internet connection available.

The minimum requirements were updated between versions 1 and 2, but 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.

Ninety-three percent of the instructions in this guide will happen in the console without making differences between operating systems.

First step is to clone the VM with:

git clone

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 if installed. If vagrant is not installed, then enter

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:

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

Once the whole process is finished we can proceed to the installation of Magento2 by entering http: // 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 the case of choosing the installation via web you need to 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 (English).

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

Dashboard access
User: admin
Password: p4ssw0rd

Some images





Admin Dashboard


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

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

Mocking with Python!

By Juan Norris, Python Developer at Santex

Here at Santex, we pride ourselves on delivering high quality software, and therefore testing is a big part of our day-to-day development process.

I’m currently working on a Python project that relies heavily on mock for unit tests. A few months ago, some new members who were not familiar with the mock library joined the team. As those of you who have used it may know, mock sometimes can be unintuitive, confusing and lead to “false positives” – passing tests that are not really testing anything – but it is also very useful and powerful.

So we found ourselves in the need of a way to explain this library a little bit, and that is why these slides were created.

We started with an introduction to what mock is and why should you use it. The slides are meant to be both a starting point and some best practices, because they explain the most important classes and helpers in the library, as well as how/when to use them and the common pitfalls you may run into.

Although there is not a lot of written information and this material is composed mostly of code examples, I hope this can get you started with Mocking in Python!

See Mocking in Python Presentation!

About Juan Norris. He is a Python/Django developer with experience in JavaScript (Jquery, AJAX), MySQL and PostgreSQL. Juan is continuously learning and training to investigate new technologies.

How to programmatically get data inside a layout XML file in Magento

A while ago, I found myself trying to answer a question in Magento StackOverflow. It was a simple question: Can I get store config value in a layout xml file?

After doing some research, I realized that it is possible to call a helper in a Magento tag inside an XML file in the following way:

<action method="addLink" translate="label title" module="catalog" ifconfig="catalog/seo/site_map">
<label>Site Map</label>
<url helper="catalog/map/getCategoryUrl" />
<title>Site Map</title>

The relevant part is

<url helper="catalog/map/getCategoryUrl" /> 

where catalog/map is the helper and getCategoryUrl is the action we are calling.

This has a lot of important applications. With this approach, anyone can get dynamic values from any Magento resource like a Model in a layout XML file and interact with blocks, change titles, or create conditionals.

Magento tutorial: How to programmatically get data inside a layout XML file

Miguel Balparda has been developing Magento for almost four 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