Why (Post-)Functional Programming Matters

“The limits of my language mean the limits of my world.” – Ludwig Wittgenstein

Computer (and computing) science (CS) is a very peculiar field of research when compared to other sciences, particularly concerning themes such as software engineering and system’s architecture. For starters, it has little more than 80 years, which puts it into an interesting proposition when compared to Physics or Mathematics: having a “conversation” with key personalities is not that unrealistic. Unlike Aristotle, Isaac Newton or Albert Einstein, many of the “genius” behind computer science are still living among us; a gentle evidence of its youth.

On the other hand, the liberal use of the term “science” (even engineering as in computing engineering), makes our Physics friends flinch at our day-to-day methodology. We don’t calculate programs. We don’t derive implementations. And when something goes wrong, our assessment method is so empirical that it would be equivalent to building a copy of the failed bridge, and observe bolt by bolt – with intuition (and stack dumps) guiding which bolts to observe first – hoping to find the one that fails. This arguable “lack of scientific rigour” is well reflected when Donald Knuth wrote one of the most rigorous treatises on computer science, and decided to call it “The Art of Computer Programming” [1].

But this constant attitude towards the synthesis of programs doesn’t mean that development cannot be made more rigorous [2], or at least more scientific or closer to the exact sciences. The hacker way of coding first, asking questions later is more due to the attractiveness of computers as a creation tool than to any inherent property (or limitation) of the field. Researchers and professionals of the so called critical systems had demonstrated this possibility years ago, with the aid of formal methods [3]. Much of this research builds upon a rigorous abstraction of computability and language, and is known as Lambda Calculus. Formalized circa 1930, it has enabled the research on the behaviour of computational systems, the creation of predictive models of its properties, and to uncover high-level patterns of computation that abstract irrelevant details and empower the creation of even more complex systems. That’s what happens when you use mathematics, and that’s what makes a science… well… scientific; much more important than the capability of explaining current observations, is the ability to “predict” yet unobserved phenomena.

But we don’t need to go into “heavy” formal systems, such as Coq or Isabelle, to reap the benefits of mathematics, and still have a practical framework to build and deploy products [4]. In fact, the 1950s gave us such tool: LISP [5].

Notwithstanding, most of the tools that we use today are not LISP based. But most are C based, and despite the fundamental differences Alan Kay introduced with Object-Oriented languages, they are (still) an imperative variant. And with imperative languages, any relation between the math behind the problem, and the implementation artefacts (source-code), is the sole responsibility of the developer. We know the mathematical model behind the QuickSort algorithm, and of the binary search in a list. But none of these relations “emerge” when we contemplate (or glance) at its source-code in C. It is, in its most fundamental sense, a list of commands that a system “rigorously” obeys [6], though it represents an extremely close model of what the CPU is doing, and as such it has enjoyed outstanding run-time performance and massive adoption [7].

On the other end of the spectrum there are the LISP (and ML) variants and other Lambda-Calculus inspirations. This isn’t about a mere syntactic preference, favouring parenthesis () over brackets {}. This is about a fundamentally different perspective, where programs no longer manipulate memory nor define their own flux, but are more regarded as algebraic equivalences and substitution of symbols, where memory and flux are implementation details of the machine. These languages are called functional because they focus on verbs, on functions and composition; mathematical functions as transformations and relations, in contrast to imperative languages that focus on nouns, on things, what they are, and their corresponding capabilities.

But discussing programming languages is hard… We know that people tend to defend their choices by considering language criticism a personal attack on themselves, and stay inside their comfort zone. Discussing programming paradigms is even more difficult; the typical Java developer may be opinionated about C#, but it will probably be very defensive against… say… Erlang or Haskell. Endless discussions over parenthesis or commas will spring to life. Code readability (whatever that is) will be summoned. Even the categories of average programmers and real-world programs will be promptly accepted as axiomatic facts of daily programming. Irony and sarcasm will reign, such as the recent dichotomy of programming being either “math” or “interpretative dance” [8].

So why give a 60 year old concept any importance? The above was tried and claimed years ago, and yet, imperative (and OO) languages are now the norm. Perhaps once we understand what Functional Programming enables us to do today (instead of discussing semantics over what it is), we will come to understand what Paul Graham once said:

“… the short explanation of why this 1950s language is not obsolete is that it was not technology but math, and math doesn’t get stale. The right thing to compare Lisp to is not 1950s hardware, but, say, the Quicksort algorithm, which was discovered in 1960 and is still the fastest general-purpose sort.”

So, without much ado, here’s the top 5 reasons Why (Post-)Functional Programming Matters for the ad-tech companies [9]:

Reason N. 5 They scale!

“The way the processor industry is going, is to add more and more cores, but nobody knows how to program those things. I mean, two, yeah; four, not really; eight, forget it.” – Steve Jobs

Pick a software architect – any architect that has drawn large-scale software systems — and ask her about design and architectural patterns, say Pipes and Filters, Client-Server or the Observer pattern; she’ll undoubtedly tell you is that they are now accepted as an invaluable tool to create, communicate and document the orchestration among the myriad of components in a large system. The legacy we inherited from Gamma et al., heavily inspired in the works of Christopher Alexander [10], goes well beyond the mere catalogue of recurrent designs. It gives us a framework to capture and systematize empirical knowledge, to uncover new relations and to think at higher levels of abstraction.

But these “classic” patterns lack something of a greater value too: they lack the mathematical formalism that allows one to reason about their structure and their interactions [11]. Let me tempt you with an example. Consider both the set of natural numbers and an operation (such as sum) over them; there are a lot of properties about the sum. First, sum is an endofunction, which is a funny way to say that if you sum two natural numbers, you get a natural number as a result. It also has the so called neutral element: if you sum something with zero, you get back the same number. Sum is also an associative operation; (1+2)+3 is equivalent to 1+(2+3). These properties – an associative endofunction with an identity – form what is known as a monoid [12].

There are endless monoids over endless types of structures. String concatenation, for example, form a monoid over strings (with the identity being the empty string). One can simply regard the fancy name monoid as a “pattern” of structures; but a different type of pattern in the sense that it is strictly defined [13].

Now your question should be: what does this matter to me, or to the construction of advertising systems? Very simple. Monoids (being associative) enjoy a very interesting property: they scale! Because (a+b+c+d) is the same thing as (a+b)+(c+d), you can send the first part (a+b) to a machine, and the second part (c+d) to another machine. The two operations can then execute in parallel, and their result can be merged by yet another machine [14]. This is very close to the fundamental ideas beyond the mapreduce model, recently popularized by Google’s implementation, and as you can see, you don’t really need to rely on such specific technologies to reap the same benefits [15].

So Functional Programming scales, because it allows the programmer to scale. It brings a multitude of powerful abstractions, which not only avoids re-inventing the wheel, but allows a more “precise” reasoning over programs, its properties and their resulting quality.

Reason N. 4 They really scale!

“The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.” – Tim Cargill

Software is more than just writing code. It’s debugging code! And there’s a root to all evil when it comes to debugging: mutability. I once spent hours of trying understand why a certain program ceased to function if I executed it step-by-step, but worked OK if I just jumped over the function. The problem? The debugger window was displaying the local variables and some good, well-intended soul, decided to override a getter to cache the result. And that specific getter function was crashing the application.

But there’s more… If we never know when objects will change, we can’t possibly know if removing an apparent superfluous call, or changing the order of execution, will output the same behaviour [16]. We’ve all seen this taken to the extreme in dynamic languages such as JavaScript. Undefined functions and fields springing to life, because some previous call defined and re-defined them. A living hell to debug. [17]

Functional Programming scales, because it gives better guarantees about the behaviour of your programs. They are easier to test, because they are more “isolated” in a certain sense. But much more important it empowers safer redesign and re-factoring; it makes program more resilient to change!

Reason N. 3 They scale even if you do nothing about it!

“A programming language is low level when its programs require attention to the irrelevant.” – Alan J. Perlis.

Now imagine if pieces of programs could be regarded as pure, i.e., having absolutely no side effects. What would this mean?

If parts of a program are pure, then one can rearrange the order of their execution. They won’t rely on any context, besides the parameters one passes to them. This key idea of FP is called “referential transparency”; functions do not behave differently the second time you look at them: you give the same inputs, you get the same result. A trivial idea with profound implications, because if there’s absolute guarantee that changing the order of execution will produce the same results, then one gains scalability for free, by, for example, executing different parts of the program in different threads or machines.

But there’s more to purity than inherent parallelization; things that really pure™ functional languages [18] take advantage of: laziness and memoization. Avoiding the risk to incur in a large technical debate over the advantages and disadvantages of such techniques, let us just state what they provide, and leave to the reader the decision over their suitability for the ad-tech industry.

Laziness and memoization could be translated to two obvious principles: “don’t compute something until you need it” and “don’t recompute something you have computed before”. Though trivial principles, the programmer usually has to be aware of them throughout the code; here’s a list, multiply the elements by two, give me the first one. Wait… why don’t I just take the first one, and multiply it by two?

And what about loading a webpage? Show me the first article (written in markdown); translate it to HTML. Show me again the first article; translate it again… A thousand of users requesting to view the first article; a thousand of translations of exactly the same content. Hmmm… Maybe we should once and for all translate the first article and store it somewhere? Let’s throw in a cache.

Suffice to say that FP – particularly due to the principle of “referential transparency” – provides the ability to tackle those concerns at the compiler level. A sufficiently advanced compiler can even achieve much of that for us… automatically; it may not throw in a cache, but it will easily memoize the results of a function whose parameters are always the same. FP scales even when you don’t make a deliberate effort for that.

Reason N. 2 They provide a new kind of glue

“Such a catalogue of “advantages” is all very well, but one must not be surprised if outsiders don’t take it too seriously. It says a lot about what functional programming isn’t (it has no assignment, no side effects, no flow of control) but not much about what it is. The functional programmer sounds rather like a mediæval monk, denying himself the pleasures of life in the hope that it will make him virtuous.” – John Hughes

So far it seems that if we strip other languages from features such as mutability and control flow, then we would have the same benefits of functional programming, without the hassle of learning a new language. Hence, the question remains: why should we care to learn FP in the first place?

Flashback circa 1968. We are near Garmisch Germany, and NATO is holding the seminal conference on “Software Engineering”. So far everyone seems to agree on one particular conclusion: software is in crisis. Projects are running over-budget, over-time, and with low quality. They are inefficient, they don’t meet the requirements, their code is difficult to maintain. Some software isn’t even delivered… ever! They realized all this before Windows™ was presented to the world. [19] Forty years later, what have we learned? [20]

From the several ideas there discussed, one of them looked at computer software as they looked at complex electronic systems: software should be componentized, i.e., built from prefabricated components [21]. Powerful idea! In the subsequent years, we saw the appearance of Unix’s Pipes and Filters, Objective-C, OLE, COM and the concept of Frameworks in general.

On the object-oriented side, a similar race gave us the AbstractSingletonProxyFactoryBean… whatever that is. [22]

The crux of modularization is a two-step process: (1) you first divide your problem into sub-problems, and then (2) you combine (glue) the results. You can look at this like an electronic circuit; you separate your problem (a computer) into sub-problems (CPU, Memory, GPU…) and then you provide the glue (copper circuits and wires that roughly match inputs with outputs).

What happens when you provide the wrong kind of glue, say, plastic instead of copper, or wire an input to another input? Best-case scenario: it doesn’t work. [23]

Another (different) way to view modularization is like a big puzzle. Pieces have a shape and they only compose if their shape match. If done correctly, you are kept safe from combining components that don’t talk to each other, simply because their shape doesn’t allow it. This is akin to the experience given by (strongly-typed) functional languages. [24] Instead of declaring capabilities of objects, you define transformations that accept things of a particular shape. For example, to filter out elements of a container structure, you don’t really need a function for every kind of containers out there (Lists, Trees…) As long as the structure you’re providing has the shape of something that can be iterated over, then you simple iterate ruling out objects that don’t match your filter. [25]

Functional programming provides new kinds of glue, such as higher-order functions, function composition, point-free definitions, type-classes and higher-kinded types. Some languages can even check these “glues” at compile time, making your program safer. You write less code, you reuse more, and it keeps you from reinventing the square wheel.

Again, consider the number of components an ad-tech platform now comprehends, yield managers, ad decision logic, RTB clients, forecast engines, logging, campaign optimizers, and you’ll understand why improving modularization (and making sure they fit with each other) is a crucial step in the industry.

Reason N. 1 Because it’s cool

“C is quirky, flawed, and an enormous success.” – Dennis M. Ritchie.

Much of the above was known more than twenty years ago, at a time where C was the de-facto king of programming languages. And yet, here we are, claiming again and again the advantages of functional programming. What really changed? Is imperative programming just getting old? Is Functional Programming becoming a hype?

The fact that C was a huge success is (arguably) a mystery [26]. C is (was) well-known, widely adopted by both the industry and the academia, and hence enjoyed an incredible amount of scrutiny. A huge amount of C libraries and frameworks became promptly available in the wild. Yes, everyone knew C wasn’t perfect. In fact, C’s unsafe type system was an imminent disaster. Turing award laureate Tony Hoare once called the “null reference” [27] its billion-dollar mistake. And yet, even today, C ranks second in the Tiobe popularity index. Why?

Perhaps the keyword here is establishment. All those frameworks and libraries and tools built for C (in C) made it the number one choice. People didn’t even think for a second. If C is popular, and has everything I need, why choose another language?

Of course, the fallacy lies in the definition of “need”… Notwithstanding, there’s a bitter lesson here, learned the hard way by Haskell proponents: if you fail to provide the complete experience, it really doesn’t matter how good your product is.

So what changed?

We’ve now come full circle to the title of this article. Maybe some of you have been wondering about the usage of the prefix (post-) in post-functional. What is different today from what we had 20 years ago, is that the functional paradigm is no longer relegated to obscure, academic corners, whimsically forcing you out of your comfort zone.

Instead, what we are now observing is a merge between object-oriented and functional languages, at different degrees of realization. At the lowest level, we see the latest version of the C++ standard (0×11), incorporate the notion of lambdas and function objects. The same is true for Java 8, and was true for C# 2.0 and all its subsequent versions. And it’s not just higher-order functions. In Biancuzzi’s book “Masterminds of Programming”, we can read Anders Hejlsberg (lead C# developer) rant on how the future of the language lies in adopting FP techniques to cope with multi-core/parallel programming. We may even go as far as Microsoft’s release of F# as a first-class language for the “big-data” industry [28], that runs on top of the CLR.

And finally we have Scala. A language created by Prof. Martin Odersky, that fuses object-orientation and functional programming at their most fundamental level. Its secret? It runs on top of the Java Virtual Machine (JVM), and seamlessly interoperates with existing Java libraries and frameworks. It was specifically designed for scaling at large, and has enjoyed several successful adoption stories in the industry, including Twitter, LinkedIn, Foursquare, and The Guardian, just to name a few. “Functional Programming Principles in Scala” [29], an MOOC held by Coursera, had more that 50.000 students registered, becoming one of the most successful on-line courses. It’s not hard to conclude that, if these players are using Scala, maybe one should keep an eye on it.

So, post-functionalism is about realizing that the ecosystem matters. Instead of trying to get people out of its comfort zone, it brings those features into what people are comfortable with [30]. Post-functionalism is about realizing that both object-oriented and functional programming can contribute to a new (merged) thing: OO is an excellent tool to design “components”, the outward limits of systems, while FP provides an invaluable tool to express its inwards. This thing is object-functional programming.

(Post-)Functionalism is now a reality. To some extent, it doesn’t really matter if you’ve been evangelized by this article. I’ve claimed that (post-)functional programming will give you better, more robust, more scalable, more modular programs. It would make you better cope with the specific needs of the fast growing industry that is the ad-tech, because the issues ad-tech has (high-availability, high-scalability, robustness, fault-tolerance, adaptiveness) are the issues that FP learned to solve decades ago. But, perhaps, the most pragmatic reason why post-functional programming matters is because you will no longer be able to ignore it.

The post Why (Post-)Functional Programming Matters appeared first on ShiftForward - online advertising technology r&d for DSPs, SSPs, DMPs, Ad Exchanges, Ad Networks, Agencies and Publishers.

A type system is, indeed, a very powerful tool for a programming language. In fact, it is a concrete case of a formal method; it provides us a near mathematical proof that programs that compile successfully obey a set of rules and restrictions and, as such, are bug-free in that respect. For example, after compiling a Java program, we know for sure that the it will not do a division of a number with a string and that, if our method foo receives an integer as argument, it will not be called anywhere with an argument of any type other than an integer.

This blog post focuses on how a programming language can be used to model more advanced code restrictions and check them at compile time. By checking them at compile time, such languages enable the detection of bugs which otherwise would only be caught at runtime, when systems are already deployed (or by manually writing tests – though tests can be wrongly written and may not cover all potential failure cases). We assume basic knowledge of Java programming, even though we feel it may not be necessary to delve into the code to understand the main problem and concepts presented.

Consider the following scenario:

• Our forecast system, at a particular stage, simulates the ad server decision mechanism in order to predict the number of hits for each campaign;
• The delivery algorithm is modelled as a component with two operations:
  • Pre-process. It must be able to pre-process a list of campaigns, yielding a structure that allows faster evaluation of delivery rules. For example, it can sort the campaigns according to their priority or index campaigns according to a targeting rule;
  • Execute. It must be able to quickly determine which campaign will be delivered for a given request, using the aforementioned structure. This decision step is done a huge number of times – once per simulated request;
• Different algorithms can yield completely different structures in the pre-processing phase;
• The algorithm must be stateless, as a single instance is shared by many concurrent threads and is used to execute many forecasts.

We want our system to be decoupled from the delivery algorithm it is using, in order for us to switch the delivery algorithm according to our clients’ needs and to easily introduce new features, such as pacing and tandem. Moreover, the specific algorithm to use may not yet be known at compile time, e.g. its name can be indicated as a string via API.

Let’s think how we could do this using Java. The most natural encoding we could do would be to make our Algorithm a generic class, like this:

public interface Algorithm<CampaignContainer> {
    CampaignContainer preprocess(List<Campaign> campaigns);
    Campaign run(CampaignContainer campaigns, Request req); // returns null if no booking was made
}

Following this approach, our main Forecast class would look like this:

public class Forecast {
    <CampaignContainer> void forecast(List<Campaign> campaigns, List<Request> requests, Algorithm<CampaignContainer> algorithm) {
        CampaignContainer preprocessedCampaigns = algorithm.preprocess(campaigns);
        List<Campaign> results = new ArrayList<>();
        for(Request req: requests) {
            results.add(algorithm.run(preprocessedCampaigns, req));
        }
        // (...)
    }
}

Note that the forecast method was also made generic, in order to accept heterogeneous Algorithm classes.

As we said before, the specific algorithm to use is not known at compile time. To instantiate an algorithm given a class name – using a mechanism known as reflection – we can do:

<CampaignContainer> Algorithm<CampaignContainer> getAlgorithm(String className) throws Exception {

    return (Algorithm< CampaignContainer>) Class.forName(className).newInstance();
}

This method will cause a compiler warning, indicating that an unsafe cast is being done. That happens because the compiler erases generic types; e.g., a program can’t distinguish between an Algorithm<String> and an Algorithm<Integer>.

However, there is a bigger problem: we don’t know which specific type is CampaignContainer when we call forecast! When we call the getAlgorithm method, we should know in advance what is the type of CampaignContainer and, as it can be anything, this solution is not suitable to support arbitrary structures as an output of the pre-processing step.

In Java, the only way we could do this is to forget about types and generics at all and make our algorithms return and receive objects of type Object (which is a superclass of every other class) instead of CampaignContainer:

interface Algorithm {

    Object preprocess(List<Campaign> campaigns);

    Campaign run(Object campaigns, Request req); // returns null if no booking was made
}

This is obviously a bad and unsafe design choice, as the run method is now able to take any object as parameter and will yield runtime errors if some method calls it in the wrong way. This also implies that, inside run, algorithms must always cast the campaigns argument to its concrete type, which is a seemingly unnecessary operation and probably expensive overall, considering that run will be called a huge number of times. (Relinquishing type-safety)

When comparing programming languages, we should evaluate for ourselves the flexibility they give us to correct and easily encode our control flows and restrictions. Let’s think for a minute here: must the Forecast class really have to know what is the campaign container? Given a specific instance of Algorithm (without any more information), the only thing we want to enforce is that the first input of the run method is of the same type as the return value of a preprocess call. Besides that, it doesn’t really matter what is the particular type of the container.

In Scala, this problem can be properly encoded using a feature called path-dependent types. Let’s see how the equivalent code in that language looks like:

trait Algorithm {

    type CampaignContainer // an abstract type field; it must be defined by subclasses

    def preprocess(campaigns: Seq[Campaign]): CampaignContainer

    def run(campaigns: CampaignContainer, req: Request): Campaign

}

class Forecast {

    def forecast(campaigns: Seq[Campaign], requests: Seq[Request], algorithm: Algorithm) {

        val preprocessedCampaigns: algorithm.CampaignContainer = algorithm.preprocess(campaigns)

        val results = requests.map { req => algorithm.run(preprocessedCampaigns, req) }

        // (...)

    }

}

Scala has the concept of abstract types: types that, just like abstract methods, must be defined by subclasses. Our CampaignContainer here is declared as an abstract type in the Algorithm class, and it is the concrete subclass of the latter that defines what a CampaignContainer is. Therefore, the abstract type CampaignContainer is dependent of the instance it refers to.

Let’s quickly see a concrete algorithm that returns a Map mapping string keys to campaigns in the pre-processing step:

class SimpleAlgorithm extends Algorithm {

    type CampaignContainer = Map[String, Campaign]

    def preprocess(campaigns: Seq[Campaign]): Map[String, Campaign] = (...) // code for creating the Map here

    def run(campaigns: Map[String, Campaign], req: Request): Option[Campaign] = (...) // code for choosing the campaign here

}

The best part is that our Forecast class – a class from the outside of this type hierarchy – can refer to this abstract type and use it in their variables. In the forecast method, our preprocessedCampaigns is an instance of algorithm.CampaignContainer; it is called a path-dependent type. This models the exact relation we wanted for our entities: independently of the concrete type of our Algorithm, we assure that the run method (that, in forecast, takes an algorithm.CampaignContainer as argument) can only take structures returned by a call to preprocess on the algorithm instance. It is important to note that all of these restrictions are enforced at compile time and, as such, do not affect the runtime performance of our system.

More advanced type systems, such as the one featured in Scala, increase our confidence in the systems we develop and help us reduce the number of bugs before deployment – which ultimately benefits, without a doubt, our clients. It is important to note that these important validations doesn’t require extra effort from developers – no need to manually write tests or to run third-party tools – and have no runtime performance impact, which is always a key concern when developing online advertisement systems.

The complete source code of this example can be seen here: AlgorithmJava and AlgorithmScala. If you are curious and have some knowledge in Java, I recommend you to compare the syntax of both languages and to read further about Scala here.

The post Scala path-dependent types – A real world example appeared first on ShiftForward - online advertising technology r&d for DSPs, SSPs, DMPs, Ad Exchanges, Ad Networks, Agencies and Publishers.

The post Binomial Queues appeared first on ShiftForward - online advertising technology r&d for DSPs, SSPs, DMPs, Ad Exchanges, Ad Networks, Agencies and Publishers.

The post Monoids appeared first on ShiftForward - online advertising technology r&d for DSPs, SSPs, DMPs, Ad Exchanges, Ad Networks, Agencies and Publishers.

The post Finger trees for the impatient appeared first on ShiftForward - online advertising technology r&d for DSPs, SSPs, DMPs, Ad Exchanges, Ad Networks, Agencies and Publishers.

Localizada no Parque de Ciência de Tecnologia da Universidade do Porto (UPTEC), a ShiftForward procura agora recém licenciados (até 3 anos de experiência) com formação em Engenharia Informática (FEUP, UM, ISEP ou equivalentes), com as seguintes características:

1. Conhecimento prévio em Microsoft .NET (C#) e frameworks associadas;
2. Conhecimento prévio de tecnologias e infra-estruturas Web;
3. Motivado para aprender novas tecnologias, novas linguagens de programação e formas avançadas de desenvolvimento;
4. Team-worker e problem-solver;
5. Nível de Inglês Europass B2 ou superior.

Oferece:

1. Contrato de trabalho inicial por 6 meses, com possibilidade de renovação e integração na empresa;
2. Integração numa equipa internacionalizada;
3. Ambiente de desenvolvimento ágil (scrum + xp);
4. Remuneração compatível com o nível de conhecimentos, acima dos valores de mercado;
5. Horário de trabalho flexível.

Para tal, os interessados devem enviar um email com o CV para info@shiftforward.eu. No caso de não terem experiência profissional prévia, agradecemos que seja anexado um resumo com as classificações de cada disciplina do curso.

The post ShiftForward Recruta Novos Colaboradores appeared first on ShiftForward - online advertising technology r&d for DSPs, SSPs, DMPs, Ad Exchanges, Ad Networks, Agencies and Publishers.

Can you give an overview of the ShiftForward proposition in Europe?

ShiftForward’s core is its know-how in technology development and its application in the online advertising industry. Online advertising has very specific technical and business requirements, often not found in other fields, that can take engineering teams a long time to be up to speed with what the business and market are talking about.

We provide this expert independent advice to companies seeking to adopt or create their own technology for various purposes, from Ad Serving to Behavioural Targeting or Data Management Platforms. This means researching and designing solutions, defining the software architecture to support it and guiding the company’s engineering teams during the development cycle.

Continue reading the full article on ExchangeWire

The post Paulo Cunha Discusses The ShiftForward Tech Development Solution, Its Value To Local European Ad Tech Players And Where It Sits In The Eco-System appeared first on ShiftForward - online advertising technology r&d for DSPs, SSPs, DMPs, Ad Exchanges, Ad Networks, Agencies and Publishers.

The post ShiftForward ^>> 1.0 appeared first on ShiftForward - online advertising technology r&d for DSPs, SSPs, DMPs, Ad Exchanges, Ad Networks, Agencies and Publishers.