Your project . The Gizra Way

About Us

Gizra is a boutique development shop in Tel Aviv, established in 2009 and employing 17 developers.

Gizra's work focuses on Open Source technologies: We've created and maintain key Drupal modules such as RESTful, Organic Groups, Message and Entity Reference, and take part in maintaining Drupal core, as well as state of the art technologies like Node.js, D3, Angular, Jekyll and others.

At Gizra we've developed an approach we call The Gizra Way, a radically transparent way of working, but technologically and project management-wise. Every Gizra project is tracked in GitHub with all code and tasks open to all stakeholders from day one. Every piece of code is peer-reviewed and covered by automatic tests. Stakeholders are encouraged to communicate directly with developers working on their code via GitHub Issues.

Gizra developers set aside an hour each day for community contributions: fixing bugs on open source projects, blogging about new code and methods we develop, and working on public-benefit software projects. We make a point of taking part in the developer community, presenting in Open Source camps and conventions worldwide.

See The Team

Work

From e-Commerce to community sites.

Commerce Kickstart

A collaboration with Commerce Guys, Commerce Kickstart is built on top of Drupal Commerce making it easier to admin and faster while adding multiple features.

Imanimo

Maternity fashion catalog and eCommerce website

Drupal Commons

We collaborated with Acquia Inc to create this social community focused Drupal distribution, complete with a user friendly interface and built in groups / activity streams support.

OpenScholar

Drupal distribution designed for higher education, allowing academic institutions to run all their staff, department and project websites on a single installation. Developed by Harvard in collaboration with Gizra, used at Princeton, Berkeley, Virginia Tech and more.

Our code

At work

Our code contribution has reached over 100K sites.

Blog

04 Dec 2014

In my previous blog post Behat - The Right Way I made a statement that I think Behat was a better choice for writing tests even for the frontend. Some good arguments were raised in favor of CasperJS.

I believe my comparison was wrong in the sense it was lacking the key point to Behat's stength for us. It's not really about "Behat vs. Casper". The proper comparison should have been "Behat vs. Casper - With a Drupal backend"

And here's the key difference: With Behat you can interact with Drupal's API even when testing using PhantomJS. That is a lot of testing power!

23 Nov 2014

The Drupal community can now proudly claim its own implementation of a Todo app with a RESTful backend!

TodoMVC is a site that helps you select the right JS MVC library. But more then that, it allows you to learn by comparing those libraries, as they all implement the same thing - a simple Todo app.

I've decided to fork the Angular example, and build it on top of RESTful. Looking at the Angular code, I was pleasantly surprised.

17 Nov 2014

Behat is a wonderful tool for automatic testing. It allows you to write your user stories and scenarios in proper English, which is then parsed by Behat and transformed to a set of clicks or other operations that mimic a real user.

If you don't have automated tests on your project, I would argue that you're doing it wrong (I explain why on The Gizra Way presentation). Even having a single test is much better than none.

With that said, it's super easy to abuse Behat. We are developers and we think sort of like machines (not really, but you get my point). If you would like to test login to your site you could easily do

Given I visit "/user/login"
 # fill the username and password input fields, and click submit
 When I fill "username" with "foo"
  And I fill "password" with "bar"
  And I press "Login"
 Then I should get a "200" HTTP response

Your test will return green, but it could be improved:

30 Oct 2014

As extremely pedantic developers we take documenting our APIs very seriously. It's not rare to see a good patch rejected in code review just because the PHPdocs weren't clear enough, or a @param wasn't declared properly.

In fact, I often explain to junior devs that the most important part of a function is its signature, and the PHPdocs. The body of the function is just "implementation details". How it communicates its meaning to the person reading it is the vital part.

But where does this whole pedantic mindset got when we open up our web-services?
I would argue that at least 95% of the developers who expose their web-service simply enable RESTws without any modifications. And here's what a developer implementing your web-service will see when visiting /node.json:

Contact Us

5 Brenner St., Tel-Aviv, Israel
+972-3-3731222