This is the second blog post of a new series entitled “Build it with the Coveo Cloud Platform”. The series will present innovative use cases for the Coveo Platform, always including full code samples. Read the previous post Building a resource locator.
Search is great. It gives you the power to find information without having to go through every page of a website. But sometimes, search alone is not enough, and you need filters and sorting options to help you find what you’re looking for. One fantastic way to narrow large sets of content is faceted navigation. In fact, faceted navigation may be the most significant search innovation of the past decades.
Saturday. 7 AM. Normally I’d be sleeping in. But alas, this Saturday is not like your regular Saturday. I’m wide awake and super hyped. No, this isn’t the first chapter of my new fantasy book, it’s real. It’s Blitzday. I’m ready to crush through code like never before.
The first time I heard about the Coveo Blitz was through a spam^H^H^H^H email from my school faculty informing me that some company I’d never heard of from Quebec was organizing a coding competition. Having nothing else to do and looking for some way to hone my coding skills, I enlisted my friends to register for the competition as a group. After all, the only requirement they asked for registration was to be able to send an email (something I, and others apparently, still fail to properly do even today).
Now that we have created a custom component, we want to test its interactions with the Coveo JavaScript Search Framework.
This post offers a deep dive into the Custom Coveo JavaScript component testing world.
In our last post about Randomizing Results from a Coveo Index, we talked about how we managed to create a search page that returns random results from our index. Following this, we wanted to have a full-fledged custom component for the sake of doing things cleanly (we love “clean” at Coveo).
This post will go in-depth about our journey to “Component-ize” our randomizer using TypeScript.
I’ve been working with the Salesforce platform at Coveo for about 3 years. In those 3 years, I always had the feeling that there was something missing in our continuous integration setup. A couple of years ago, we’ve automated the process of creating a managed package using PhantomJS. As a software developer, this is a well-deserved upgrade.
Since then, we were able to gain a lot of speed in our release process. But still, there was something missing. There was a void in my developer life. Demoing, reviewing, and testing new features on our package was near impossible and needed a lot of effort. Since Salesforce organizations can’t be created easily, a developer had to create a new org, push all the code to that org from their machine, give credentials to everyone, etc. A lot of works on my machine(TM) and Jenkins is weird happened using that method.
Continuous integration (CI) is the act of automatically compiling code and running its tests every time a change is made. It is an important step in a project to ensure quality and save time. It needs to be implemented before continuously deploying an application.
In this post, I will explore how to configure CI with AppVeyor using the Sitecore Habitat demo project.
Companies are becoming more and more aware of the importance of offering a good search experience on their website. From increases in purchases on ecommerce websites to getting fewer cases on their support and community websites, companies are realizing that helping users find what they are looking for faster and more easily results in a great overall experience.
In the previous blog post, I explained why having a prominent search box is essential. In the second part of this series, I will talk about the key elements to have in your search result page.