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

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:

19 Oct 2014

What's the name of the Angular component for login?

The difficulties in creating a semi or fully decoupled site isn't in the RESTful part. Spitting out JSON is now covered by several modules, including RESTful which aims for a "best practices" solution.

One of the real problems, though, is how to prevent us, the community, from re-inventing the wheel over and over again. Basically, how do we package our frontend code similarly to how we package our generic backend code - AKA "modules". I discussed these problems, and offered some solutions in my "BoF" persentation:

24 Jul 2014

Defining moment

A few months ago my DrupalCon Austin session was rejected. I was a bit upset, since presenting plays a big part in my trip to the states, and also surprised, as I mistakenly assumed my presentation repertoire would almost guarantee my session would be accepted. But the committee decided differently.

This has been an important moment for me. Two days later I told myself I don't care. I mean, I cared about the presentation, I just stopped caring that it was not selected, since I decided I was going to do it anyway. As an "unplugged" BoF.

The Gizra Way. I think this is probably the best presentation I've given so far, and quite ironically my rejected session is second only to Dries's keynote in YouTube.

You see - I had a "there is no spoon" moment. The second I realized it can be done differently, I was on my own track, perhaps even setting the path for others.

Form API, Drupal 9

I use Drupal because Form API is so great

No one, ever

14 Jul 2014

In our last example we showed how to create node using an angular form served from Drupal itself. This time we are taking one big step further and create the node from a completely decoupled web app.
And if that's not enough for the readers excited by the idea of a decoupled Drupal, we've also added inline editing to the example!

Enjoy the live demo

If you know Form API's pains, you should be excited now

Contact Us

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