If you have been in touch with the Liferay community in the past years, you've probably heard about Senna.js before.

We first introduced this project in late 2014 and since then we've been anxiously waiting for Liferay 7 and DXP to be released so we could talk more about it. Now it's a good time to see what this project brings to the table.

Ok, so what is Senna.js?

Senna.js is a super fast single page application engine that can dramatically optimize any site's performance. It's open source and doesn't require any dependency.

But what is a Single Page Application?

Even though this term may not be familiar with non-technical people, chances are you already interacted with dozens of applications like this. If you ever used Gmail, Facebook, or Google Docs, then you had the experience of using a SPA.

Basically, a Single Page Application (SPA) is a web app that loads all of the resources required to navigate throughout the site on the first page load. As the user clicks links and interacts with the page, subsequent content is loaded dynamically.

The application often updates the URL in the address bar to emulate traditional page navigation, but another full page request is never made. This is possible due to new browser capabilities like the HTML5 History API.

There are many frameworks for single page applications out there. First we had Backbone, then Ember, then Angular, now React. They all had their ups and downs, but we decided to create our own lightweight solution for many reasons:

First, because Senna.js was built for a single purpose, SPA, rather than being a fully-featured framework. Second, so you don't necessarily need to learn a new technology every time the JavaScript community comes with a new library.

How does it affect Liferay DXP?

As I told before, Senna.js can improve the performance of any site. By optimizing speed we can make incredible advances in terms of user experience, and that's crucial for Liferay DXP to be successful.

Ok, enough with the blah blah blah, let's see the difference between having Senna.js enabled and disabled when using Liferay DXP with a 3G connection.

I don't know about you, but we think that a 13-second difference for a single page navigation is HUGE.

Want to learn more?

Below you can find an entire talk about this topic. Also make sure you check sennajs.com for more technical details and examples.

And that's it! Any questions? Feel free to leave a comment :)

Contenus relatifs:

Back in October when we first introduced Launchpad Developer Preview, we put together a very simple documentation page for users. After seeing how people were interacting with the product we realized we needed a more robust structure.

We pushed tons of improvements but still one of the challenges for every documentation is how easy people can find the content they are looking for. That's why we decided to use Launchpad's powerful search capabilities. On this tutorial, you'll understand step by step how we solved this problem.

1. Creating a datastore in the cloud

First thing you need to do is go to liferay.io and access your account. Once you get to the dashboard, click on "Create App" (which is called "Docs" on this case) and "Create Service" (which is called "Search" on this case). Now, that we defined a namespace (/docs/search), it's time to actually create this microservice using the API Builder.

We can start with a name and description that will help other team members to maintain this API in the future. Then, we can toggle the "Data" switcher which will turn this simple endpoint into a powerful NoSQL datastore.

If you don't have an account yet, just request an invite at liferay.io

2. Indexing the content

Even though our product is not open source, we wanted a very simple way for people to contribute to the documentation. That's why we decided to write everything in markdown and manage it on a public GitHub repository.

Now you might be wondering, how do we index this type of content? Well, that's the easy part.

The cool thing about Launchpad is that everything is a microservice, so we just make a HTTP POST request to that API endpoint we created earlier.

In our case, we also wrote a 5-line NodeJS script that go through these markdown files and structure them on a JSON object before sending it to Launchpad. But you can literally structure your data in whatever format you like.

3. Fetching the content

Once we have our content stored in the cloud, we need a way to fetch it too.

Fortunately, we can use the API Builder again, but this time we'll create a HTTP GET method to the same endpoint.

You can even check if your API is really working by using the API Explorer

4. Showing it in your app

We configured our datastore, we indexed our content, and we created an API to get this content. All this in like 5 minutes. Now it comes the fun part: coding!

Another cool thing about Launchpad is the API Client it provides. In our case, we want to create a search autocomplete with JavaScript so we'll just use the JavaScript API Client.

And remember, Launchpad is all about REST APIs. There are many many ways we could fetch this data, feel free to use any programming language you prefer.

If you have any questions, please leave a comment. I hope this article can help you understand the power of Launchpad. Next time you need a search engine, remember that Launchpad can help you :)

This is an initiative that we have been working for months and not many people had access to. Now, we're finally ready to share the news with all Liferay engineers.

What is the Launchpad Project?

The new Launchpad Project aims to be your project's back-end, period. Ambitious, I know, but Launchpad is a very versatile tool that does just that. Launchpad allows you to create REST APIs instantly, add a powerful cloud database, use a fast static hosting, and leverage real-time capabilities in your app. Regardless of what platform you work with, you'll be able to use native SDKs for mobile, desktop, and IoT devices.

Why should I use Launchpad?

When building a high scalable application there are many things you need to consider: performance bottlenecks, database resiliency and scalability, authentication, authorization, and static hosting to name a few. Launchpad is a new dynamic Liferay initiative, allowing you to handle all of your back-end challenges in one place. Focus on creating amazing user experiences, and Launchpad will take care of the rest.

How does Launchpad interact with your existing Liferay Portal solution?

Launchpad can be described as Liferay's API Gateway that can also be used standalone. Launchpad provides an infrastructure to deploy micro-services in a managed cloud infrastructure. Launchpad will have prebuilt adapters for Liferay services like document repository, content management, audience targeting, etc. You may create additional microservices that integrate with other enterprise applications like SAP, Salesforce, etc.

Using Launchpad, you may augment your existing Liferay solution with real-time notifications and a cloud based microservices platform.

Can I rely on Launchpad for apps in production?

The closed developer preview version of Launchpad is intended to collect developers feedback. We don't recommend you use it for production at this point.

Can Launchpad be installed on my own servers?

Launchpad's initial goal is to provide Backend as a Service deployed in the cloud. Most of the complexities of scaling and fault tolerance of your application is automatically managed by Launchpad.

What's next for this project?

There is still lots of questions to be answered, dozens of documentation to be written, and tons of features to be implemented. That's exactly why we decided to open this for the community. We need your feedback in order to create something awesome.

At Liferay we have more than 600 employees spread in 18 different offices all over the world. Some of these people work with similar stuff but they may not interact with each other since they are working in different projects.

This is an interesting problem to solve.

Many companies think that just by using an instant messaging tool like Slack you're covered but the truth is, nothing replaces human interaction.

Inspired by Spotify's engineering culture, we're adopting this concept of Guilds which are basically groups of people that share knowledge, tools, and practices among different teams.

Even though they’re not working in the same project, there’s a lot of opportunity for these people to learn from each other since they all share a similar workflow.

Logistics

After coming up with a list of 28 participants, we had to figure out accommodations, transportation, food, and all that.

Taking care of logistics is a painful process. You need to know what time each person is arriving and departing, book hotel reservations, find out if they have food restrictions or not, book restaurant reservations, arrange transportation from airport to hotel, hotel to office, office to restaurants, restaurants to hotel, hotel to airport. Did I mention touristic activities too?

Once you finish organizing all that, you'll need to make sure that everything is going to be there on time and suppliers will not let you down. This is especially difficult in a country like Brazil.

Fortunately, I had some incredible people next to me and everything went smoothly.

Agenda

So you flew twenty developers to Brazil for a week, now what?

Coming up with an interesting and productive agenda wasn't an easy too.

Several weeks before the event we sent a survey asking all participants what they would be interested in hearing or speaking about.

They shared some ideas and we started the schedule from there.

Talks were designed to be a quick explanation of a topic that could be related to Liferay or not. For more in-depth subjects, we had workshops that were meant to be a full hands-on demonstration.

For more philosophical debates, we held an unconference where participants propose topics and discussions are self-organized.

Besides that, we also had interviews where we would ask team leads what they have been struggling with and what are their next goals.

I must say, it was an extremely busy week. We were all exhausted in the end but from what I heard it was pretty rewarding too.

Thanks!

We went to beautiful beaches, we ate at some of the best restaurants in town, we had tons of caipirinhas, and most importantly we learned a lot from each other.

I believe we all came back with a better understanding of what’s going on in the company and stronger relationships that will help us accomplish great things at work.

Really, it couldn’t be better than that, so thanks for being a part of it!

One of the cool things about working at Liferay is that you have the freedom to propose any crazy idea that comes to your head and there’s a high chance that they might like it. You know, like stopping the company’s Engineering department to work on different projects for an entire day.

Of course, I know that Hackathon's are not a new thing (some companies do that all the time), but we never had the chance to organize one and since our annual engineering retreat in Los Angeles was getting closer. This could be a pretty good opportunity to do it in order to encourage more innovation, open source, and collaboration.

Our first Liferay Hackday concluded on December 19th and it was incredible! We had more than 60 registrations and 8 teams show up to participate. Here's how it was it…

Preparation

Once I got the "ok" from the VP of Engineering, Jorge Ferrer, it was time to start preparing everything. I've attended dozens of tech conferences and several hackathons but event organization was never my thing. Besides that, there were lots of projects and traveling going on so I just couldn't afford to pause everything to arrange all the event needs.

That's how Joshua Kuo got in the scene. His daily job was working with Project Management, but during the nights he was my partner in crime arranging everything from branded glassware to Costco snacks. Not only that, we also had to coordinate numerous issues with Marketing, HR, Facilities, Design, and Web teams.

Our ultimate goal was to create an event where everybody could have fun and learn. However, we didn't have too much time to set everything up. In a few weeks, engineers from all over the world were about to arrive in Liferay's Headquarters and we had to communicate the details on our Hackathon on time. Otherwise, airplane tickets were going to be bought and we would lose the opportunity to have them participating (which unfortunately happened to some people).

Kickstart

On December 19th, at 8:30am, we opened the doors and people started to come. Registration was pretty straightforward, just a simple name check. We waited until we had the room full so we could start giving instructions and setting expectations for that day.

After this, we asked them to start writing their ideas on the paper. If they didn't have any, that was ok because they could help someone to make their idea come true. Those who had ideas had to come in front of everybody to pitch. They had 1 minute to explain what they wanted to do and describe what kind of resources they needed to make that idea happen. For example: "I want to produce Star Wars Episode IX and I need 2 back-end developers and 1 designer".

Recruiting was pretty organic and self-organized, each team had a maximum of five members and we encouraged them to choose people that didn't belong to their usual teams and offices.

However, they only had couple hours to make something entirely new from the ground up, so we simulated a very chaotic environment with some loud music and a huge countdown.

Also, we tried to be as minimally intrusive as we could be, which means that things like food were served asynchronously through the day. Interruptions were made just to see if everything was ok and to check if they were still alive. Eventually, we played some Platform4Emotion too.

Judges

At 6pm everybody had to stop coding and move to the presentation area. Four rockstar judges were waiting for them to present their achievements.

Each judge have a different key role in the company, that way they could analyze each project with an unique perspective.

Awards

The idea was not having one single winner. Therefore, we created four different categories that all projects had to be judged on.

Best Technical Achievement — Did the participants solve a hard technical problem? Did they get a working demo completed within the allotted time?

Best User Experience — Is it easy to interact and understand? How do you feel about using such it?

Most Innovative Solution — Could this be a radical innovation or a meaningful new take on an existing product or service?

Most Impactful Project — How does this changes the life of developers, employees, clients, partners, or end-users?

Winners

By now you are probably curious about what all those people created, right? Don't worry, we recorded every single presentation!

After all presentations (and pizza slices), we got the score sheets from the judges so we could check who were the winners.

For "Best Technical Achievement", a team who played with hardware by moving a robot, taking photos and uploading it to Twitter, and controlling a light bulb by detecting the level of sound. All this using Tessel, a microcontroller that runs JavaScript.

For "Best User Experience", an app called Audité that provides a way for audiences to connect to people who are giving presentations. Basically, you could ask questions using SMS or through the web and the administrator could filter and display those questions. Their technology stack is made of iOS, Tropo, and Parse.

For “Most Impactful Project”, a connector between Liferay Portal and IBM's Lotus Notes. For those who don't know, Lotus Notes is a product used by lots of enterprise companies and many have trouble with it because of all this huge legacy code built on top of it. This integration allows data to be fetched from Lotus Notes to Liferay's Calendar and Document Library.

Finally, for “Most Innovative Solution”, an iOS app to improve engagement for Liferay's EVP (Employee Volunteer Program). The idea is that employees could easily post stories about their initiatives for other people to see and interact with. Also, one of the cool thing about this project is that it was built on top Liferay Screens.

Thanks!

A special thank you to all the judges who were able to come out of their busy schedule to help make this event possible. Also to the web team who developed the site, the design team who helped not only with the logo, but all the decoration and posters, and everybody that participated.

We're really excited about how can we make this even better for 2015. There are many ideas floating around, we want to include more and more people from other departments besides Engineering like QA, Design, and Support. Not only that, but what about bringing this to the community? What if we organize a hack day right after one of our conferences? As you can see, there are a bunch of cool things that we want to do.

But most importantly, what we want is to encourage people to make things different and have fun with it, doesn't matter if you work for Liferay or not.

All modules have been improved to work well on mobile devices (AUI-1294), a big effort around accessibility has started (AUI-1347), all dependencies are now being fetched using Bower (AUI-1213), each module now lists its changelog in the HISTORY.md file (AUI-1273), a huge number of unit tests were added (AUI-1275), and the Rosetta Stone guide has been updated.

Bootstrap and YUI updated

Starting from our dependencies, YUI has been updated from version 3.16 to 3.18. Nothing really interesting here, just a bunch of bug fixes (go to their releases page for full changelog).

We finally updated Bootstrap from version 2.3.2 to 3.2.0 and this brings a lots of improvements. Grids have been changed to provide a mobile first approach, shadows have been dropped in favor to flat design, and image sprites have been replaced by font icons (go to their releases page for full changelog).

Automated tasks switched from Grunt to Gulp

Some of you may be familiar with Gulp and some of you may not. Task runners are small applications that are used to automate many of the time consuming, boring tasks that you have to do while developing.

When we moved from Ant to Grunt, we had a huge performance improvement. But we didn't stop there, we want to provide the most productive workflow possible for those who contribute to our project. Gulp is based on streams and this gives you more control over your flow and relieves you of temporary folders and files.

And more!

There were a total of 975 commits for this upcoming release by 24 contributors, you can check the detailed changelog by using the GitHub Comparison to version 2.5.0 or by checking our HISTORY.md files located in each module.

Now, two years after that day, here I am to share some of the things I learned.

Passion is the most important skill

Hiring is a very delicate topic in every tech company nowadays. As developers we’re usually doing more stuff than we should do. And we all know how hard is to find talented people, specially if you’re very selective with who you hire.

I had the opportunity to interview some people and it’s interesting to find out that those who got the job are not always the most skilled developers or designers. They simply demonstrated more passion about what they were doing.

After all, we think that learning technical skills is much easier than changing how someone feel about doing their work.

This is a very nice thing, but when you go deep into a particular community you may end up forgetting that there are other communities out there. Communities with much bigger problems to solve. Communities that could use your help somehow.

The mentoring cascade

The way I see, Brian Chan, the company founder, grew the engineering teams with an amazing mentoring cascade model.

It’s really hard to describe how it works because it’s a kind of mentoring that goes beyond code review. We spend a huge amount of time teaching other people.

Brian mentored Nate, Nate mentored Eduardo and a bunch other guys, Eduardo mentored me and a bunch of other guys too, now I’m mentoring Henrique, Thiago and so on.

The cool thing is that I’m just one leaf of that tree, there are many other leaves like that spread all over the world.

People before profit

Last year I went to Europe for couple presentations and ended up in a hospital in Madrid for 3 weeks. I got there alone and had many troubles to communicate since I don’t speak Spanish very well and they didn’t understand English or Portuguese at all.

Fortunately, many of my coworkers from the Spain office went there to visit me. They were all very friendly, trying to entertain me all the time. They even brought my Macbook and a 3G USB modem, so I could “escape” from that situation using a computer (interesting fact: the dracula theme was created in that hospital).

During the second week there, I had to leave my room for 15 seconds and when I got back my computer and tablet were stolen.

The only way I had to communicate with my family was gone. I was totally devastated.

Again Liferay was very kind to me. They brought me a new computer, some DVDs to watch, and most importantly they flew my sister all the way from Rio to Madrid just to be there with me.

Those were, by far, the worst 3 weeks of my life. But I learned so much from it. Specially ‘cause those are the moments that you truly get to know those around you.

Any other company could be angry because I wasn’t working for a long time, worried about the hospital bill or simply didn’t care at all. But not Liferay. They did much more than I could expect and for that I'll be always grateful.

Couple months ago Cleydyr and I were invited to be part of Liferay's EVP (Employee Volunteer Program) committee in Latin America.

We couldn't say no to this amazing program and we're now very happy to announce our first initiative.

It all started on a regular Monday (05/26) at 10:30am when Cleydyr showed me the website of the Farol52 ONG and we noticed this campaign called "1.000 kg of food in 10 days" to help poor families in the state of Pernambuco. Every year this region of Brazil suffers a lot because of long periods without any rain.

We knew that gathering this huge ammount of food in few days was a really hard challenge so we decided to help. At 12pm we got everybody together to explain the campaign. If each person could help with some little ammount of money through the EVP program we could still buy lots of food.

Everybody loved the idea and in less than 2 hours we had already collected R$ 3.160,00 ($1414.18). But we still needed to move fast in order to meet the deadline.

In the afternoon, we ordered 100 baskets of food, 7 kg (15 pounds) each. And in the following day (05/27), more than 700 kg (1543 pounds) of food were delivered to the Liferay Recife office.

On Friday (05/29), a day before the collection ended, our amazing staff helped with transportation to the collection point.

And we also managed to find some time to record, edit, and publish a video on Youtube to tell a little bit more about this initiative and to invite other companies to do the same kind of donation.

On Saturday (05/30), the campaign has ended with 2392 kg (5273 pounds) of food and R$ 2.755,92 ($1233.35) in cash donations collected. About 30% of all food collected thanks to Liferay employees.

We're proud to work in a company like Liferay. A company that cares about the community and gives the opportunity for its employees to make a difference in other people's lifes.

Also the AlloyUI website has also been updated to reflect the changes in this release.

What's new?

It's been 6 months since 2.0.0 so, as you can imagine, lots of things changed since then.

About our dependencies, YUI has been updated from 3.11.0 to 3.16.0 (go to their releases page for changelog). I know you are all excited for Bootstrap 3.0.0, but I must say that we're still using Bootstrap 2.3.2 in this version. You'll need to await for AlloyUI 3 to use Bootstrap 3, but don't worry it will be available sooner than you think (go to master branch to see the work in progress).

One of the things that we really improved in this release is the API Docs. Since last year we've been working hard to document all classes, attributes and methods. We're now really close from finishing this task (AUI-1048) and you can see the result online at alloyui.com/api.

Lastly, a big refactoring was also done in the entire code base regarding constants. Old browsers (IE) doesn't handle memory for strings in a good way, that's why we used constants for memory optimization which, nowadays, is not a big deal anymore (AUI-1163).

Button

We fixed a bug that duplicates icon due to labelHTML attribute added by YUI 3.15.0 (AUI-1211);

We fixed a bug in the Search Button Cancel when an input was removed from and placed back in DOM (AUI-1161).

Carousel

A new attribute was introduced to allow you pause the Carousel when mouse is over it (AUI-1192).

Collection

We fixed a bug where the map hashcode for object could conflict with string hashcode (AUI-1172).

Color Picker

We fixed a bug when adjusting the value via the slider. The newly selected color didn't get reflected in the results view. In addition, the background color of the slider was being set to colors with a value of less than 100 (AUI-1083);

We fixed a bug when user opens the palette for choosing custom color and types something in the HEX value text field, the view updates, but on closing the palette, the value was not being updated (AUI-1091).

DataTable

We fixed a bug when user edits a selectbox's data and creates an empty option or empty value, it couldn't be saved. Options with empty option-text or value were deleted (AUI-1194);

We fixed a bug when user edits a selectbox's data and try to add a new option, it failed. Nothing happened, just an error in the console (AUI-1195).

DataType

We fixed a bug when the mask which is triggered by an input text box contains "{{%b %e %m}}" and values below 10 were selected, the date which is output was incorrect (AUI-1027).

DatePicker

We fixed a bug when date disappears from input textbox when choosing the minimumDate (AUI-1177).

Diagram Builder

We fixed a bug when the browser window are scrollable and you drag a node to bottom of viewport and scroll in the same moment the node moved down to out of viewport (AUI-1203);

We fixed a bug when browser redirected page when trying to delete the selected connector (AUI-1191);

Modal

Pagination

Palette

We fixed a bug when setting objects as items were not working properly (AUI-1033).

Popover

We decoupled animation logic from tooltip-base to a new widget called Widget Transition (AUI-1162);

We fixed a bug when popover would not center align after its first visible toggle (AUI-1096).

Rating

We fixed a bug when the rate average is a float number was not rounded (corresponding the rounding rules) just the decimal value would be removed (eg.: 1.5 -> 1). So the display of the rate was incorrect (AUI-1250);

We fixed a bug that was not allowing the user to navigate via the items using keyboard, nor to press Enter to vote (AUI-1132).

Scheduler

We updated the Scheduler View Table to show abbreviated weekday names (AUI-1085).

Toggler

We fixed a bug when absolutely positing elements that end up in an accordian would overflow from their container when sliding (AUI-1105).

Tooltip

We decoupled animation logic from tooltip-base to a new widget called Widget Transition (AUI-1162);

We updated tooltip to stay open when hovering over help box (AUI-1092).

Tree

We fixed a bug when TreeNode does not show "Load More Results" link (AUI-1156);

We fixed a bug when Tree hitarea icon were not changed when treeview was generated from markup (AUI-1141);

We fixed a bug when TreeNodeTask should have a state for when one of its children was unchecked (AUI-1138);

We fixed a bug when Treeview showed hit-place for dropping when dropping was forbidden (AUI-1114);

We added an option to prevent selecting all child nodes in radio and task (AUI-1044).

When we first started AlloyUI 2.0 development we realized that we needed a better build tool for the project. Although Ant could do the job, it was not as fast and easy as NodeJS's solutions. So we decided to switch and rewrite all our automated tasks.

At that time, YUI was using Yogi to automate tasks via command line and as usual we decided to follow their path since our projects share a very similar architecture.

As time passed by, we realized that we were creating a new task-runner in JavaScript and there were plenty other projects that we could build on top of, specially Grunt the most popular one with lots of plugins.

In July 23, 2013 we released the last version of Yogi Alloy and started focusing our work in Grunt tasks instead. All tasks were ported following similar APIs, new ones have been added, and now it's time to say goodbye to Yogi Alloy.

We're very happy to announce several talks focused on the AlloyUI project at Liferay official events. If you're coming to any of those conferences below, enjoy that time to get in touch with our team members!

Liferay Developer Conference (Berlin, Germany)

On October, 9-10 will happen the Liferay Developer Conference, the first of its kind. It's going to be specifically targeted at developers and IT technical staff, so be prepared to dive deep, get your hands dirty, and to have a lot of fun!

Day 1 - Neil Griffin will show how to integrate JSF components with AlloyUI using Liferay Faces Alloy project at 10:00am and Zeno Rocha will be giving the closing keynote about Liferay's 6.2 UI revolution.

Day 2 - Iliyan Peychev will introduce AutoComplete for Velocity and FreeMarker languages at 10:00am, Nate Cavanaugh will talk about responsive web design at 11:00am and Zeno Rocha will give another talk about AlloyUI 2.0 at 11:40am.

Liferay Symposium Spain (Madrid, Spain)

Liferay Symposium North America (San Francisco, USA)

From Europe to North America. Join Eduardo Lundgren and Jonathan Mak in a 3-hour workshop that will happen on Sunday, 20th October at 3:00pm about how to use AlloyUI 1.7 on portlet development. Besides that Nathan Cavanaugh will talk about AutoComplete for Velocity and FreeMarker languages on Monday, 21nd October at 4:10pm. Finally on Tuesday, 22nd October, Nathan will present how Mobile Web Development works in Liferay at 9:50am andZeno Rocha will be speaking about AlloyUI 2.0 at 10:50am.

When I first met the AlloyUI project was a little bit hard to understand all the functionalities it provides without looking to the source code. Then we made a new website that shows how can you use each component with some code snippets.

That was great, but how can you check which are the configuration options available for each component? For instance, you know that there are options like contentBox, height and width on Carousel, but they are not the only one, there are plenty more configurations that you could use.

That's why we have the API Docs, that is generated based on the source code, pretty similar to JavaDoc. The only problem was: most part of the source code doesn't have documentation at all, so the API Docs became outdated :(

We had to change that, so after a couple days of hard work we added the necessary markup for documentation on all attributes, properties and methods. So now we are able to document, we just need to actually explain how each part of the code works.

Current Status

At this moment, there's a total of 109 JavaScript files on AlloyUI core.

29 are documented;

64 needs to be documented;

16 can't be documented.

To track what files are documented or not, we made public this status list on Github. If you want to join us on this quest to make AlloyUI better, make sure to check this list to find out what needs to be done.

Contributing

Let's say you want to help and just discovered that aui-autocomplete.js needs documentation. If you navigate through the code you'll see a lot of attributes, properties or methods that doesn't have description yet, for example:

All you need to do is understand what that piece of code stands for, explain it and send a pull request :)

Bonus

Additionally, if you have Yogi Alloy installed and want to check how the documentation will look in the website, you can run ya api-watch to generate the API Docs locally and watch for any changes.

New Theme

Together with all those new things, we're also introducing today a new theme for API Docs! Forget the old one:

This task can't be done by a single person, there's a lot of code to document and we need your help. Here, at Liferay Brazil, we started this thing called Daily Docs, so everyday at 5pm an alarm rings and we need to stop everything to spend 10 minutes improving the documentation of a certain component. Those kind of initiatives could be very helpful, so if you care about this project, please join us :)

Some weeks ago we announced the preview release of AlloyUI 2.0. One of the cool things about it is that now we have a pretty new CDN (Content Delivery Network). So instead of downloading AlloyUI to use in your local environment, you just to need copy and paste this line of code and start using it.

Why it's so important to use a file hosted on a CDN?

Basically for performance improvements, we'll dig into some of them.

Decrease latency

Let's say you are in China and your server is in Los Angeles. When you load a file the browsers sends a HTTP request that will go across the globe until reach your server and, as you can see, it takes time.

However if this file is hosted on a CDN it will be distributed across many different servers in the world. So when you make a request, it will look for the nearest server, which decreases latency time a lot.

More parallel downloads

Browsers can't handle too many parallel downloads per domain.

That's why hosting files in different domains is a good performance tip.

Cache

Let's say you visited a website that uses AlloyUI hosted on CDN, as soon as you load it your browser will automatically cache it in your machine. Then if you visit another website that uses AlloyUI too, you don't need to download all those files again because you already have cached them.

What's the real benefit?

Let's try those performance improvements in real life. My experiment will load the exact same file using a CDN and don't using it.

Didn't use CDN:

When you load this file, that is not hosted on a CDN with a 10mb internet connection, you take 1.27 seconds with 404ms of latency.

Use CDN:

But when you load this file, that is now hosted on a CDN with the same internet connection, you take 314ms with 155ms of latency.

That's a 75% decrease and this is only one file!

Now imagine a lot of modules and its dependencies being loaded, it will cause a significant difference.

Conclusion

And that's all folks! If you have any questions please comment below :)

People started to talk about it and suddenly I received a lot of congratulations messages for being the #50 most active contributor on Github.

I was pretty happy because this is a chance to show how Liferay employees are strong in the open source community. But I was mostly surprised, since there’s almost 2 million users on Github and even because Linus Torvalds, creator of Linux, was behind me!

That was pretty nice for my ego, but let me explain what this ranking means for me.

Quantity != Quality

The first thing is, I’m not better than anyone.

Just because I made 100 commits more than Linus, it doesn’t make me a better contributor than him. Actually I could do 10,000 commits more than him and I would still not being a better contributor.

The only thing that these numbers shows is: those people on the list put a lot of effort on open source using Github.

And this is true, I've been working hard on the new AlloyUI and many other projects out there.

People just don’t get “commits”

We all have a lot of tasks to do daily, so how to deal with them using Git?