Business Intelligence (BI) is a field of computer-science the goal of which is to build decision support systems.
According to Wikipedia, BI involves the means, the tools and the methods used to collect, consolidate and produce the data model, and to finally display it. It is designed:
- to help a company taking decisions;
- to cover its whole activity for people in charge of the strategy.
Simply put, BI is the art of transforming raw data into valuable information.
This article begins with an introduction to BI, then describes the main actors of the BI market, and what their products are designed for.
Some operations are not as easy in SQL as in procedural or imperative languages. For example while it is very intuitive to make an update or insert (also known as “upsert”) operation on a
std::vector in C++, it is tricky in SQL. The upsert operation is: update data if already in the set and insert it otherwise.
Gallery3, a web based photo album organizer, can extract the
IPTC.Caption field of photos you import. This caption is then used to set the description of photos. However, this default behavior might not be what you would expect. Read more…
This article will focus on the ability to write recursive queries using Common Table Expressions (CTE). CTE are an addition from the SQL 1999 standard and are not yet available in all DBMS. As of today, CTE are at least compatible with:
- Microsoft SQL Server 2000 / 2005 / 2008
- IBM DB2
- Oracle 9.2
If you have ever tried to write parallel scripts / applications using Ruby’s threads, you may have stumbled over the fact that, sometimes, some cores are left unused. You may be especially sad if you notice that your brand new war-machine, with 2 physical cores or more, is not fully exploited.
Then, you would be right to wonder if using Ruby and taking advantage of multicore (i.e. writing multithreaded applications) are compatible.
The simple answer is yes. Let’s dig into the more complicated answers: we’ll first explain how Ruby’s threads work, then explain why they sometimes seem to be broken, and eventually suggest four efficient solutions to get rid of their limitations.
Search Based Applications (SBA) are applications based on search engines. They are designed for users who want to discover and analyse information. They usually require processing large amounts of data, processing data in real-time or handling unstructured or semi-structured data, among others. To handle these requirements, they benefit from the appropriate processes already used by search engines (scalable foundations and natural language processing, for example).
Input data can be structured (databases…) but also unstructured (Office documents, PDF, mails…) or even coming from other applications (ERP, CRM, intranet, extranet…).
Unlike traditional search engines, SBA provide ad-hoc interfaces to data (dashboards, mashups…), so that the user can access the right information without necessarily having to perform requests manually (in the context of BI, for example, it allows him to take the good decision on time by giving him a relevant view of the data).
Notice the difference between discovering and searching: when searching, the user knows what he is looking for; when discovering, he starts by searching something, which brings him to a final point he may not have expected. Think about it: discovering is what we need when taking decisions. Why? Because even if we know what information we need we may not know how to get it. Discovering helps users to take better decisions.
The expressivity and power of Ruby make it a really efficient programming language. Its dynamic nature results in lots of enjoyable benefits (introspection, dynamic class reopening…); it is also responsible for a part of its performances, which are sometimes believed to be poor.
Is Ruby really slow? While being obviously slower than most natively compiled languages, is the performance gap really worth noticing and should it prevent you from using this great language?
If all you’re coming for is pure performance benchmarks, you may directly skip to the last part of this article (“Lies, damned lies, and benchmarks”), since this article does not aim at benchmarking Ruby.