for Romanian version click here

1. About Lucian Ghindă
Lucian, aside from a lot of beautiful references that characterize you, including from a professional standpoint ☺, please tell me what does DevAcademy mean? How was this project thought out/ what does it want to achieve and how much has it achieved so far?

DevAcademy wants to create an environment set towards technological innovation and the creation of software in Romania. Practically, the way we hope to achieve this is by building a community of teams made up of elite programmers.
Right now, access to this community is gained through a process that includes interviews and a 6 learning program. At the end of this program, teams are formed. Each team goes through a process of choosing a software idea that they will implement for a few months. In this stage, DevAcademy brings to these technical teams mentors (senior programmers), to help overcome any technical difficulties, product managers to develop the products, and designated promoters for those products.
However, in this stage of creating a real software, the main purpose is directed more at the innovative aspect of the product and the size of the impact it can have in the lives of potential users.
Just last month we finished the Ruby on Rails learning program and, for about two weeks, the teams have begun working on their own applications.

2. Why Ruby?

We chose Ruby on rails for 4 main reasons:
• It’s a framework that we know (I’m especially referring to our team of mentors) so well, that we hope to achieve greatness using it, in the current context of software applications.
• Ruby as a language and Rails as a Web framework, bring a mentality of eliminating a lot of the blockages a programmer might have with the language’s details, which allows for more time to think about what we actually want our application to do. If we refer specifically to Romania, there are very few Ruby on Rails senior programmers compared to the international market where their number is higher and growing.
• There is a large and active community of programmers that contributes to both Ruby and Rails, and develops a lot of add-ons (they’re called “gems”). In other words, this open-source Ruby on Rails environment is an effervescent one, which means that it’s a mature programming language that is constantly growing.
• We think it’s great for start-ups because it allows for fast application development, especially when talking about the Rails framework. Some of the projects developed by the DevAcademy community will go in this direction of building and launching start-ups.

3. From Ruby on Rails to Java.

I admit that the real reason behind this interview was to find out what you think about Java, as a manager and a trainer that has coordinated various teams of programmers that were using multiple programming languages. I know that, aside from Ruby on Rails, you’ve also worked with JavaScript, which some call “a cousin of Java” ☺. Am I getting closer to the Java developed by Sun? Is there a similarity between these two programming languages? I found that “Java is a programming language, JavaScript is a scripting language”. Is that correct? And if so, then what exactly does that mean, for a non-programmer?

Java and JavaScript are two very different programming languages. Java is a strongly typed OOP language (Object Oriented Programming) basically, meaning that you need to declare beforehand what type of data is a certain variable. JavaScript is an ECMAScript implementation. So it’s a scripting language in which OOP implementation is not standard (it only implements certain concepts) and is a weakly typed language. That means that a variable can stock any type of data without having to declare it beforehand.
The only similarity between the two is that the syntax is inspired by the C syntax in both of them. Basically, as someone once said (on StockOverflow) Java and JavaScript are as similar as car and carpet.

4. APIs (an introduction)

I will use your knowledge in the field of programming languages in general, and I’m going to ask your opinion on several technical aspects. I will start with API. Why? Because of the recently re-opened software war between Oracle and Google, currently considered to having the potential of changing programming/coding forever.

5. Pamela Samuelson recently said, referring directly to the dispute between Google and Oracle:

” (…) a computer program designed to be compatible with another program must conform precisely to the API of the first program which establishes rules about how other programs must send and receive information so that the two programs can work together to execute specific tasks“.
“(…)once that the API exists, it becomes a constraint on the design of follow-on programs developed to interoperate with it.”

True or False? ☺ What is an API? Can you tell me how an API can influence a derivative of the initial program or a completely independent development, but which is meant to be compatible with the original?

Basically, API comes from Application Programming Interface. Simply put, an API represents a series of rules and specifications about how different components or software interact with each other.
On the basis of the fact that an API represents a multitude of rules, it can constrain, in a certain way, development of a derivative of the initial program, if that derivative proposes to respect the API of the “parent” program.
If we’re talking about a completely independent software development that wants to respect an existing API, that API can somewhat influence the development of the new software.
Still, in both instances we’re talking about the creation of new software, that tries to respect a series of rules. These rules do not influence the creativity, internal architecture or the way in which algorithms are implemented. It influences what the things this software shows the world looks, more than anything.
I would make a comparison (maybe a little bold) between programming language and our language. The fact that a lot of people use the same language (therefore the same communication “interface”, with the same rules), does not mean that those people are identical, not even similar in evolution, physical appearance or thought.

6. In your experience, and the experiences of the programmers you’ve worked with, is there really a necessity for software compatibility? How important is compatibility in the process of creating new software products and for innovation in general?

I don’t know if I can make such a general statement, whether there needs to be compatibility or not.
There is a term in software development called “Interoperability” (described for the first time in as a standard in ISO 9126). Interoperability is described as being the capacity of a software system to interact with one or more systems or components.
If we’re talking about the creation process, interoperability is a characteristic that you would introduce in the design process. In most cases, I don’t think it uniquely determines the way in which the architecture is implemented. Considering that you’re asking about innovation, then the answer should be more nuanced. Maybe there are cases in which interoperability uniquely determine the architecture of a software. Interoperability, in principle, only determines the way in which a system interacts with another. But this can be a very small part (in most cases) of what a software is.
A good example (albeit not necessarily innovative, as it already exists), could be this: I want to create a software that takes offers from insurance companies and, considering a client’s needs, offers the best insurance policy. Of course, in this software, I need to interact (to read data) from each software the insurance companies use. But the purpose, or the innovation of my software is not its ability to read data, or its interface, but the algorithm through which it chooses the best insurance policy for a client.

7. Maybe more to the point, could there still be new software development/creation if all programs had compatibility limitations, in the sense of restrictions due to copyrights and patents?

There shouldn’t be any limitation regarding compatibility. The direction in which we are heading is one of interconnectivity: your phone connects to your car, to the refrigerator and the central heating. A limitation here sounds more like a monopoly for whoever thought of it first. And this sort of monopoly stops progress. On the contrary, I think that progress happens when things are free. Take for example Elon Musk and Tesla, who opened their patents to the public. Now that is a step towards the real revolution of the electric car.

7. EFF (Electonic Frontier Foundation): “The free and open use of APIs has been routine in the computer industry since its beginning.”
Modern cloud computing providers like Amazon Web Services rely on a reimplementation of one of the oldest APIs: the IBM BIOS. Cloud computing allows users to rent space and processing power on distant servers, accessible from anywhere in the world via the Internet. At their core, cloud computing clusters act as “virtual machines”—imitations of small computers being run on huge servers. Virtual machines call the functions of the BIOS API just like physical computers, but they have no individual physical hardware. Instead, a reimplementation of the BIOS API allows the server to answer the API calls of all the virtual machines running on it. Cloud computing providers also use an API to govern how their users can interact with their services. Most providers rely on Amazon’s cloud services API to allow users to control and operate the cloud computers that they rent. Today, since major cloud service providers like Amazon, Eucalyptus, and CloudStack use the same standard specifications for their APIs, their customers can easily switch from one cloud service to another.

The example above regards cloud computing, about which I know you would have something to say, but the main idea I would take is that APIs are not only specific to the Java program created by Sun, on the contrary, they can be found in most software and their usage has become mainstream. True or false? Can you give me another example aside from Cloud?

Yes, APIs have become a widespread practice in software, especially in the last 5-7 years. APIs are a part of many good practice concepts in the software industry. That means that some ways of creating and API can become a common way of thinking among a lot of programmers and software developers. It’s as if we tried to protect the “if” in programming. I agree that the first one to come up with this idea was an innovator in the sense that they took a concept from a programming language and brought it in IT. But now the “if” is so widely used that there is no point in looking to put a patent on it.
Moreover, the Java APIs issue is just one case in many in which the concept of API is brought up. And herein, I think, the rules comparison becomes useful: APIs are some rules about how you can communicate with a certain program/component. Putting a patent on it is like putting a patent on a set of rules.
Besides Cloud, APIs are widely used: there are APIs for the interaction between operating systems (Windows API, POSIX). But we can take more palpable examples: Facebook has an API through which I can interact with their system without accessing the web interface. All the websites that allow Facebook authentication are implemented using the specifications in their API. Or, if we’re talking about Facebook, there is a Graph API with which you can obtain data (without using the web page) that is either public or has been made available by each user of an application through an agreement. Basically, if I send a call to graph.facebook.com that would look like GET /{friendlist-id}, then I can obtain information about a certain list of friends from a profile.
That is a concrete example of an API. I mean that GET followed by a unique list identifier. That exact same syntax can be implemented by any other program. Because it is a derivative of the natural language: “Get me the list of friends with the identifier X,” that is schematically transformed into that GET /{friendlist-id}.
Here’s another example: With Instagram, in order to get the public information of a profile with the unique identifier 11, there is a “GET/users/11” API call made; with Twitter, there the call looks like “GET/users/show?user_id=11”. If we look at them closely, we find they are very similar. That’s because they both come from the same transformation of the natural language: “Get me the user with ID 11 from the list of users.”

Despre Software, Inovație și API, Inverviu cu Lucian Ghindă, DevAcademy

1. Despre Lucian Ghindă/Despre DevAcademy.

Lucian, pe lângă multe referințe frumoase care te caracterizează, inclusiv din punct de vedere profesional :), spune-mi te rog ce înseamnă DevAcademy, cum a fost gândit proiectul/ce se dorește a fi și cât a reușit să realizeze până în prezent.

DevAcademy își propune să creeze un mediu orientat către inovația tehnologică și crearea de software în România.
Modul concret prin care noi vrem să realizăm acest lucru este construirea unei comunități de echipe de programatori de elită.

În acest moment accesul în această comunitate se face printr-un proces care include interviuri și trecerea printr-un program de învățare de 6 luni.
La finalul unui astfel de program se formează echipe. Fiecare echipă trece printr-un proces de alegere a unei idei de software pe care o implementeză timp de câteva luni. În această etapă DevAcademy aduce lângă echipa tehnica mentori (programatori seniori) pentru depășirea unor dificultăți tehnice, product manageri pentru dezvoltarea produselor și persoane dedicate pentru promovarea acelor produse.
Totuși în acest modul de creare a unui software real, scopul principal este mai mult orientat către caracterul inovativ al unui astfel de produs și dimensiunea impactului pe care o poate avea în viața unor potențiali utilizatori.

Chiar luna trecută am încheiat programul de învățare Ruby on Rails și de aproximativ 2 săptămâni echipele au început să lucreze la propriile aplicații.

2. De ce Ruby?

De ce ai ales dezvoltarea pe această platformă open-source și care este plusul adus de Ruby on Rails în industrie?

Am ales Ruby on Rails din 4 motive principale:
1. Este un framework pe care îl cunoaștem (mă refer aici mai ales la echipa de mentori) atât de bine încât să ne propunem să facem performanță cu ajutorul lui în contextul actual al aplicațiilor software.
2. Ruby ca limbaj și Rails ca framework Web elimină mult din blocajele pe care un programator le-ar putea avea cu detalii ale limbajului și asta permite mai mult timp să ne gândim la ce vrem să se întâmple cu adevărat în aplicație. Dacă vorbim specific de România sunt puțini programatori seniori Ruby on Rails, spre deosebire de piața internațională unde numărul lor este mare și este în creștere.
3. Există o comunitate mare și activă de programatori care contribuie atât la Ruby cât și la Rails și dezvolta foarte multe add-on-uri (se numesc “gem-uri”). Cu alte cuvinte acest mediu open-source Ruby on Rails este efervescent și asta înseamnă că este un limbaj matur care este în continuă creștere.
4. Credem că este potrivit pentru start-up-uri pentru că permite dezvoltare rapidă a aplicațiilor mai ales când vorbim de framework-ul Rails. Unele dintre proiectele dezvoltate de comunitatea DevAcademy vor merge în această direcție de construire și de lansare de startup-uri.

3. De la Ruby on Rails la Java.

Admit că scopul ascuns al interviului a fost de a afla ce crede despre Java un manager și trainer care a coordonat de-a lungul timpului diverse echipe de programatori ce utilizau multiple limbaje de programare. Știu că, pe lângă Ruby ai avut de-a face și cu JavaScrip, pe care unii îl numesc “cousin of Java” :). Reușesc sau nu să mă apropii de acel Java dezvoltat de Sun? Există vreo similaritate între aceste limbaje de programare? Am găsit “Java is programming language JavaScript is a scripting language” , este oare corect? și dacă da, atunci ce înseamnă mai exact pentru non-programatori?

Java și JavaScript sunt doua limbaje de programare diferite. Java este un limbaj OOP (Object Oriented Programming) în principiu strongly typed, adică trebuie să declari apriori ce tip de dată este o anumită variabilă.
JavaScript este o implementare de ECMAScript. Deci este un limbaj de scripting în care implementare de OOP nu este standard (ci implementează doar anumite concepte) și este weakly typed ceea ce înseamnă că o variabilă poate să stocheze orice tip de dată fără să fie nevoie să declari apriori.
Singura asemănare dintre ele este că syntaxa este inspirată în cazul ambelor din syntaxa C.
Practic, cineva spunea (pe StackOverflow) că Java și JavaScript sunt la fel de similare cum sunt Car și Carpet.

4. APIs
Am să mă folosesc de cunoștințele tale din domeniul limbajelor de programare în general, și am să îți cer opinia în ceea ce privește mai multe aspecte tehnice.
Voi începe cu API. De ce? Pentru că recentul caz Oracle v Google a redeschis războiul software, fiind considerat în prezent ca având potențialul de a schimba pentru totdeauna programarea/activitatea de coding.

5. Într-o opinie recentă cu legătură directă asupra disputei dintre Google și Oracle, Pamela Samuelson spunea:

” (…) a computer program designed to be compatible with another program must conform precisely to the API of the first program which establishes rules about how other programs must send and receive information so that the two programs can work together to execute specific tasks”.

“(…)once that the API exists, it becomes a constraint on the design of follow-on programs developed to interoperate with it”

Adevărat sau fals? 🙂 Ce este un API? Îmi poți spune în ce fel poate influența un API un derivat al programului inițial sau o dezvoltare total independentă, dar care se dorește a fi compatibilă cu originalul?

În principiu API vine de la Application Programming Interface. Mai practic un API reprezintă o serie de reguli și specificații despre cum interacționează între ele diverse componente sau software.
Pe baza faptului că un API reprezintă mulțimea unor reguli el poate să constrângă într-un anumit mod dezvoltarea unui derivat al programului inițial, dacă acel derivat își propune să respecte API-ul programului părinte.
Dacă vorbim de o dezvoltare total independentă a unui software care vrea să respecte un API existent, acel API poate să influențeze într-o anumită măsură dezvoltarea noului software.
Totuși, în ambele situații, vorbim despre crearea unor noi software-uri care încearcă să respecte o serie de reguli. Aceste reguli nu influențează creativitatea, arhitectura internă sau modul în care sunt implementați algoritmii. Mai mult influențează cum arată lucrurile pe care aceste software le expun în lume.
Aș face aici o comparație (poate puțin îndrăzneață) cu limba. Faptul că mai multe persoane folosesc aceeași limbă (deci aceeași interfață de comunicare cu aceleași reguli) nu înseamnă că acele persoane sunt identice, nici măcar asemănătoare ca formare, construcție, gândire sau fizic.

6. Din experiența ta și a programatorilor cu care ai lucrat, există într-adevăr o necesitate a compatibilității software? Cât înseamnă compatibilitatea în procesul de creare de noi produse software, pentru inovație în general?

Nu știu dacă pot să fac o afirmație așa de generală că trebuie sau nu trebuie să existe compatiblitate.
Există în software termenul de Interoperability (descris prima dată în mod standard în ISO 9126). Interoperability este descris acolo ca fiind capacitatea unui sistem software de a interacționa cu unul sau mai multe componente sau sisteme.

Dacă vorbim de procesul de creație interoperabilitatea este o carcateristică pe care o introduci în procesul de design. În marea majoritate a cazurilor nu cred că determină în mod unic modul în care se implementează aceea arhitectură. Având în vedere că mă întrebi de inovație, atunci răspunsul trebuie să fie mai nuanțat puțin. Poate sunt cazuri în care interoperabilitatea determină în mod unic arhitectura unui software. Dar îmi este greu să văd acum un astfel de caz. Interoperabilitatea determină în principiu doar modul în care un sistem interacționează cu altul. Dar aceasta este o parte foarte mică (în majoritatea cazurilor) din ce înseamnă un software.
Uite un astfel de exemplu ar putea să fie următorul (nu neapărat inovativ pentru că există deja): Îmi propun să creez un software care ia ofertele de asigurări de la asiguratori și în funcție de nevoile unui client îi oferă cea mai bună ofertă. Normal că în acest software eu trebuie să interacționez (să citesc date) de la fiecare software al asiguratorilor. Dar scopul sau inovația software-ului nu constă în citirea datelor sau în interfațare ci în algoritmul prin care aleg care ofertă se potrivește.

7. Poate mai în concret, s-ar mai putea creea/dezvolta software dacă toate programele preexistente ar avea limitări în ceea ce privește compatibilitatea, în sensul restricțiilor derivate din copyright sau brevete?

Nu ar trebui să avem limitari privind compatibilitatea. Direcția în care ne îndreptăm este de interconectare: telefonul se conectează la mașină, la frigider și la centrala electrică. O limitare aici aduce puțin a poziție de monopol pentru cel care a gândit primul asta. Și o astfel de poziție oprește progresul. Din contra cred că progresul se întâmplă atunci când lucrurile sunt libere. Vezi exemplul lui Elon Musk și Tesla care au deschis patentele lor publicului larg. Abia acesta este un pas către adevărata revoluție a mașinilor electrice.

7. EFF (Electonic Frontier Foundation): “The free and open use of APIs has been routine in the computer industry since its beginning.”
Modern cloud computing providers like Amazon Web Services rely on a reimplementation of one of the oldest APIs: the IBM BIOS. Cloud computing allows users to rent space and processing power on distant servers, accessible from anywhere in the world via the Internet. At their core, cloud computing clusters act as “virtual machines”—imitations of small computers being run on huge servers. Virtual machines call the functions of the BIOS API just like physical computers, but they have no individual physical hardware. Instead, a reimplementation of the BIOS API allows the server to answer the API calls of all the virtual machines running on it. Cloud computing providers also use an API to govern how their users can interact with their services. Most providers rely on Amazon’s cloud services API to allow users to control and operate the cloud computers that they rent. Today, since major cloud service providers like Amazon, Eucalyptus, and CloudStack use the same standard specifications for their APIs, their customers can easily switch from one cloud service to another.”

Exemplul de mai sus vizează cloud computing-ul, la care de asemenea știu că ai avea ceva de spus, dar ideea pe care aș desprinde-o în principal este că API-urile nu sunt specifice doar programului Java creat de Sun, dimpotrivă, se regăsesc la nivelul majorității software și mai mult, utilizarea acestora a devenit o uzanță în industrie. Adevărat sau fals? Poți da un alt exemplu în afară de cloud?

Da, API-ule sunt o practică foarte răspândită în software mai ales în ultimii 5-7 ani. API-urile sunt parte a multor concepte de bune practici în industria de software. Asta înseamnă că unele moduri de a crea un API devine un mod de gândire comun multor programatori sau dezvoltatori de software. Este ca și cum acum am încerca să protejăm IF-ul din programare. Sunt de acord că primul care a venit cu această idee a făcut o inovație în sensul că a luat un concept dintr-o limbă și l-a adus in IT. Dar acum IF-ul este așa de răspândit încât nu mai are sens să ne punem problema patentului.

Mai mult problema API-urilor Java este doar un caz din multe în care apare conceptul de API.

Și cred că aici este foarte utilă comparația cu regulile: API-urile sunt niște reguli despre cum poți să comunici cu un anumit program/componentă.
Ca să pui un patent pe așa ceva este ca și cum ai pune un patent pe o serie de reguli.

În afară de Cloud se folosesc API-uri în multe domenii: Există API-uri pentru interacțiunea cu sistemele de operare ( Windows API, POSIX ). Dar putem să luam exemple și mai concrete: Facebook are un API prin care pot să interacționez cu sistemul lor fără să accesez interfața Web. Toate locurile unde ai posibilitatea să te autentifici folosind contul de Facebook sunt implementate folosindu-se de specificațiile API-ului lor. Sau dacă vorbim de Facebook exista Graph API cu care pot obține date (fără a folosi pagina web) disponibile public sau pe baza unui accept prealabil de către fiecare utilizator al unei anumite aplicații. Concret dacă fac un apel la graph.facebook.com la care trimit un apel de forma GET /{friendlist-id} atunci pot să obțin informații despre o anumită lista de prieteni din cadrul unui profil.
Ăsta este un exemplu concret de API. Adică acel “GET” urmat de un identificator unic al unei liste.
Exact aceeași sintaxă de apel o poate implementa orice alt program. Pentru că este derivată din limbajul natural “Dă-mi lista de prieteni cu identificatorul X” care se transformă schematic in acel GET {friendlist-id}.

Uite un alt exemplu: La Instagram pentru a lua informațiile publice ale unui profil cu identificatorul unic 11 se trimite un apel API de forma “GET /users/11”, iar la Twitter se trimite un apel de forma “GET /users/show?user_id=11”. Dacă ne uităm puțin la ele sunt foarte asemănătoare. Pentru că ambele provin din aceeași transformare a limbajului natural “Dă-mi din lista de utilizatori pe cel cu ID-ul 11” ( “Get the user with id 11 from all users” ).