The initial 1-1s after joining Glints were highly productive, I received a lot of feedback, both on things I should continue doing and things I should stop doing. During that time, my manager ran my 1-1s. He asked great questions starting from how I was feeling in day to day work to how I thought I was moving along in my career with some good retrospective questions mixed in there.

But after 4-5 months, the 1-1s did feel not as productive as before. After completed a 1-1; within the next few days, I always found myself thinking of things I missed to discuss with my manager, things I needed advice on. I put all the onus of running an effective 1-1 on my manager with me being a little bit of passive actor in the 1-1s.

This continued for a few months, after which I tried to come up with a solution to overcome the problem of me missing discussion points in our 1-1. I started keeping a log of things to discuss with my manager on notion throughout the week, which helped cover all my points of discussion in the 1-1 session but boy did the 1-1 session started becoming too long at that point. Thankfully, my manager was accommodating of the extended time, but it isn't a good sign if every session ran over its intended time.

One more thing I noticed was that since I kept the log of the things I wanted to discuss in my private Notion, most of the points where I needed advice from my manager were new to him. While, I could get advice on most of the things I had written down in my agenda, for some of the things, my manager also needed time to think through since he's also human.

To solve these two problems, I started preparing agenda on our shared 1-1 document in advance for him to review. That was a game changer in our 1-1s moving forward. The agenda had 2 kind of points:

• Points tagged with [Update] at their beginning. These were things that were good for my manager to be aware of, to be in touch with what's happening at the ground.

• Points tagged with [Discussion] at their beginning. These are points that I need to discuss for the improvement of the team, personal career planning or anything that I need to get advice or brainstorm on.

Having my manager have a pre-read of the agenda helped with 2 things:

• The updates could be read ahead of time and that was time saved for the other important discussions

• Having discussions listed down helped me prioritise and time-box each discussion to fit the designated session time

• It gave my manager some time to think about the problems before having the 1-1 agenda with me

• I stopped missing important things to discuss

• One of the main points was that it reduced any blindspots from the manager side, while every manager might have good questions to sus out important points of discussion, it is unrealistic to expect that those questions will cover all the things that are important to you.

• I've had two managers over my course at Glints, both amazing mentors and it felt like setting the agenda from my side helped me get the best value I can from the opportunity of having those mentors to give me advice.

ABOVE ALL: My career development is my responsibility, setting my agenda every 1-1 has provided with a higher ownership of my own development, which would not be possible by being less active in my career development journey. I realised early on that someone setting my goals for me just doesn't work in terms of development.

While this requires significant pre-work from my side, the effort has been worth it in most of the cases. But having this pre-work means that I don't religiously set the agenda every time, but try to aim to do it 70% of the time which goes a long way.

• A simple UI for non-tech people to control the experiments

• Language agnostic with client libraries in multiple languages

• Actively maintained project (we started with Unleash v3 and now we are using Unleash v4 with significant improvement in terms of features)

What is Unleash?

Unleash is an open-source feature management platform. It provides a great overview of all feature toggles/flags across all your applications and services.

Architecture overview:

This is what our architecture with unleash looks like. We have the unleash server which is responsible for storing all the feature toggles, their strategies and their history along with all the unleash user info.

We do not directly access unleash via our front end clients. That would expose unnecessary information about the feature toggles that the user doesn't need to know e.g. which features have been disabled for them. The API server acts as a proxy between the front end clients and the unleash server.

The Glints API server connects to the unleash server to get the data of existing feature toggles. Using this data, the proxy endpoint gives a list of feature flags that have been enabled for the user along with the variant if it exists when requested by the client. Absence of a feature flag from the list should be perceived that the feature flag has been disabled for that user.

The API endpoint would return the feature flags based on the unleash-context provided by the front end client.

Would the unleash server being down affect my application?

Not at all. This is one of the things that we love about Unleash.

All of the Unleash SDKs (unleash-client-node in our case) do something called local evaluation. That means that only the information about a feature toggle is stored on the unleash server, but assigning a user to a variant A or a variant B happens via the SDK. This means that if your unleash server is down, your feature flags would still keep on working on the last known state without any updates possible to the existing state.

Does unleash come with built in tools to analyse the performance of each variant of the A/B test?

No, we use Amplitude at Glints to analyse how each of our variants in the tests are performing. We think its for the best since Unleash is a feature management platform and it does that 1 thing right instead of trying to dip its toes in multiple places.

Checkout https://docs.getunleash.io/ to get started on Unleash!

[Monday 4:00 pm] Michael, a backend engineer with very little knowledge of the frontend codebase gets stuck while trying to solve a frontend bug. In a normal working situation, Michael would go to John's desk, the frontend engineer in the team and clarify the doubt in person. But since the whole team has been working remote since the pandemic, he drops a message to John on Slack. He attaches a code block in the message and asks Hi John, can you guide how can I make this code work successfully?.

[Tuesday 09:00 am] John starts his morning routine of going through the previous day's slack mentions and notices the above message from Michael. Although John is the most experienced frontend engineer on the team, John has no clue how to respond to the question since he does not know what problem is Michael trying to solve. John drops a message to Michael asking for a link to the bug that John is trying to solve.

[Tuesday 03:00 pm] Michael is going through his slack notifs after lunch and notices John has asked for the bug link, so Michael messages that link to John.

[Wednesday 09:00 am] John notices the bug link from Michael in his mentions, he goes through the bug and thinks of an alternative solution to the one that Michael gave and drops a message to Michael with that solution.

[Wednesday 10:00 am] Michael has been more frequent to check his slack in anticipation of John's reply. He notices the alternative solution proposed by John, but turns out he has already tried that solution and it does not quite solve the problem due to a weird edge case. He gets back to John with the details of his previous attempt.

This back and forth keeps on going on till Friday when John finally realizes on how the bug can be solved from Michael's information. The conversation around the bug took them 4 days to resolve. If both of the engineers were working in person, would this conversation have taken them 4 days to solve with the questions asked same way line to line? The answer would be no, since all of John's question about the problem would have been answered immediately instead of waiting for hours. The conversation would have taken at most an hour to resolve instead of 4 days.

What's the problem here, is Michael just bad at asking questions? But that can't be, Michael has been asking questions the same way as he did before. The example here is a bit of an hyperbole on how expensive asynchronous communication can be sometimes if we follow the same rules as real time communication. Following are points to keep in mind when trying to ask questions asynchronously:

• Give the full Context. (Clearly state what you're trying to do)Instead of just trying to ask what's wrong with the code, Michael could have started his message with Hey, I was trying to solve [bug_link_here], where the popup doesn't appear on condition x . This message would give John more context on what's the problem in the first place. Additional thing to keep in mind when trying to give John context is to assume that John is completely clueless on the ideal behaviour of that part of the codebase, since John is not an all knowing deity.

• Outline your previous attempts to solve the problem.Michael had tried 2-3 solutions that didn't work before going to John for help. It would help John narrow down the problem if he was aware of those attempts and what Michael had already tried.

• Describe what's the problem that you're facing in your attempt.Just describing your attempts isn't enough, please describe what you've tried before.

Aside from the points described above, please be specific in what you are trying to point i.e. use this, that and it as less as possible. E.g. if you're referencing a column, explicitly name that column, don't assume the person on the other side knows what you're talking about. If you're referencing a commit, give a hash of that commit or even better, drop a link to a specific line of code at a specific revision on GitLab/GitHub.

Although these points might help you frame your better questions, the best way to get better at asking questions would be to ask a co-worker of yours to help you create a feedback loop. You agree that whenever you ask that co-worker any question, that co-worker would point out the flaws in your questions immediately and help you give feedback then and there on how you could you have better framed the question to help your co-worker understand the problem in the first go.

What Was The Need For Dasherizing The Attributes In The API ?

All the attributes in our database models are seperated by underscores i.e first name would be stored as first_name. But most of the API client implementations support dasherized attributes by default. In order to attract third party client implementations in the future and making the API easy to setup for them was the primary reason behind this decision. Note: The dasherized version for first_name will be first-name. Also to quote the official json-api spec recommendation for the same:

Member names SHOULD contain only the characters “a-z” (U+0061 to U+007A), “0-9” (U+0030 to U+0039), and the hyphen minus (U+002D HYPHEN-MINUS, “-“) as separator between multiple words.

flask-rest-jsonapi is the API framework used by the project. We were able to dasherize the API responses and requests by adding inflect=dasherize to each API schema, where dasherize iss the following function:

def dasherize(text):
    return text.replace('_', '-')

flask-rest-jsonapi also provides powerful features like the following through query params:

• Sparse fieldsets

• Sorting

• Include related objects

But we observed that the query params were not being dasherized which rendered the above awesome features useless :( . The reason for this was that flask-rest-jsonapi took the query params as-is and search for them in the API schema. As Python variable names cannot contain a dash, naming the attributes with a dash in the internal API schema was out of the question.

For adding dasherizing support to the query params, change in the QueryStringManager located at querystring.py of the framework root are required. A config variable named DASHERIZE_API was added to turn this feature on and off.

Following Are The Changes Required For Dasherizing Query Params:

For Sparse Fieldsets in the fields function, replace the following line:

result[key] = [value]

with

if current_app.config['DASHERIZE_API'] is True:
    result[key] = [value.replace('-', '_')]
else:
    result[key] = [value]

For sorting, in the sorting function, replace the following line:

field = sort_field.replace('-', '')

with

if current_app.config['DASHERIZE_API'] is True:
    field = sort_field[0].replace('-', '') + sort_field[1:].replace('-', '_')
else:
    field = sort_field[0].replace('-', '') + sort_field[1:]

For Include related objects, in include function, replace the following line:

return include_param.split(',') if include_param else []

with

if include_param:
    param_results = []
    for param in include_param.split(','):
        if current_app.config['DASHERIZE_API'] is True:
            param = param.replace('-', '_')
        param_results.append(param)
    return param_results
return []

What Is Sentry ?

Sentry provides open source error tracking that shows you every crash in your stack as it happens, with the details needed to prioritize, identify, reproduce, and fix each issue.

We enabled the basic error tracking with the following two simple lines,

from raven.contrib.flask import Sentry
sentry = Sentry(app, dsn='https://<key>:<secret>@sentry.io/<project>')

But after sometime, we noticed that we were not catching any app-related error in Sentry, while migration related errors were being caught. This meant that sentry was functioning properly in the app, but it was having some trouble in identifying uncaught exceptions.

After a lot of digging, it came to our knowledge that our api framework, flask-rest-jsonapi caught all unknown exceptions while dispatching the request. After catching the exceptions, it gave a jsonapi error with status 500 in return. Following is the code responsible for that:

except Exception as e:
            if current_app.config['DEBUG'] is True:
                raise e
            exc = JsonApiException('', 'Unknown error')
            return make_response(json.dumps(jsonapi_errors([exc.to_dict()])),
                                 exc.status,
                                 headers)

We now had to let these exceptions go uncaught and that required us to modify the api framework. So we modified the api-framework’s exception handling as shown below

if 'API_PROPOGATE_UNCAUGHT_EXCEPTIONS' in current_app.config:
                if current_app.config['API_PROPOGATE_UNCAUGHT_EXCEPTIONS'] is True:
                    raise
            if current_app.config['DEBUG'] is True:
                raise e
            exc = JsonApiException({'pointer': ''}, 'Unknown error')
            return make_response(json.dumps(jsonapi_errors([exc.to_dict()])),
                                 exc.status,
                                 headers)

A config parameter named API_PROPOGATE_UNCAUGHT_EXCEPTIONS was added to the config to turn this feature on or off.

But with all this done, we were able to catch errors with sentry, but the json-api spec compliant error messages on an unknown error were not being returned due to this new change. So it was decided to handle these uncaught exceptions in the app itself. We used flask’s default error handlers to tackle this situation

@app.errorhandler(500)
def internal_server_error(error):
    exc = JsonApiException({'pointer': ''}, 'Unknown error')
    return make_response(json.dumps(jsonapi_errors([exc.to_dict()])), exc.status,
                         {'Content-Type': 'application/vnd.api+json'})

Thus, all uncaught exceptions were now returning a proper json-api spec compliant error response.

Related links:

• Flask error handlers: http://flask.pocoo.org/docs/0.12/patterns/errorpages/#error-handlers

• Json-api spec: http://jsonapi.org/

• Json-api errors: http://jsonapi.org/examples/#error-objects

The Open Event Project offers event managers a platform to organize all kinds of events including concerts, conferences, summits and regular meetups. In the server part of the project, the issue at hand was to perform multiple tasks in background(we use celery for this) whenever some changes occured wither in the event, or the speakers/sessions associated with the event.

The usual approach to this would be applying a function call after any relevant changes are made. But the statements making these changes were distributed all over the project at multiple places. It would be cumbersome to add 3-4 function calls(which are irrelevant to the function they are being executed) in so may places. Moreover, the code would get unstructured with this and it would be really hard to maintain this code over time.

That’s when signals came to our rescue. From Flask 0.6, there is integrated support for signalling in Flask, refer http://flask.pocoo.org/docs/latest/signals/ . The Blinker library is used here to implement signals. If you’re coming from some other language, signals are analogous to events.

Given below is the code to create named signals in a custom namespace:

from blinker import Namespace

event_signals = Namespace()
speakers_modified = event_signals.signal('event_json_modified')

If you want to emit a signal, you can do so by calling the send() method:

speakers_modified.send(current_app._get_current_object(), event_id=event.id, speaker_id=speaker.id)

From the user guide itself: Try to always pick a good sender. If you have a class that is emitting a signal, pass self as sender. If you are emitting a signal from a random function, you can pass current_app._get_current_object() as sender.

To subscribe to a signal, blinker provides neat decorator based signal subscriptions.

@speakers_modified.connect
def name_of_signal_handler(app, **kwargs):

Some Design Decisions:

When sending the signal, the signal may be sending lots of information, which your signal may or may not want. e.g when you have multiple subscribers listening to the same signal. Some of the information sent by the signal may not be of use to your specific function. Thus we decided to enforce the pattern below to ensure flexibility throughout the project.

@speakers_modified.connect
def new_handler(app, **kwargs):
# do whatever you want to do with kwargs['event_id']

In this case, the function new_handler needs to perform some task solely based on the event_id. If the function was of the form def new_handler(app, event_id), an error would be raised by the app. A big plus of this approach, if you want to send some more info with the signal, for the sake of example, if you also want to send speaker_name along with the signal, this pattern ensures that no error is raised by any of the subscribers defined before this change was made.

When To Use Signals And When Not ?

The call to send a signal will of course be lying in another function itself. The signal and the function should be independent of each other. If the task done by any of the signal subscribers, even remotely affects your current function, a signal shouldn’t be used, use a fucntion call instead.

That’s all for now. Have some fun signaling ;) .

There was always something that fascinated me about the web.I started out with web development in the first year of my undergrad and over the summer I thought it was time to apply these skills on some real projects. So I was looking for an open source organisation to contribute and sharpen my skills, and that’s when I came across fossasia. The community was so welcoming and wonderful and the Open Event project (eventyay) just caught my eye.

So let me tell you a little bit more about fossasia’s Open Event Project. Open Event project is a fully-fledged event management system along with its own website generator and android app generator. You can find more about the project here.

I started out with the Webapp repo of the Open Event project of fossasia in September last year and actively contributed to it over the next two months(and learned a lot !!). I also started contributing to the Open Event Orga Server in the meantime. Thats when I heard about the Codeheat contest. Code Heat or aptly said ‘In The Heat Of Code’ is a coding contest with a focus on three projects:

• The Open Event Orga Server

• AskSusi Project

• Loklak Project

I continued contributing to the server project whenever I got some free time. Meanwhile I also mentored in Google Code In for fossasia(What a lovely experience it was, but thats a topic for a whole another blog post). Then came the End semester Winter break in december(Yay!! to some free time). And thus began a coding streak and I tried to contribute to the project, solving issues, adding features as much as I can. I got to learn some exciting new things and practices as I continued solving issues. The project became a whole lot active during this period and it certainly was a lot of fun contributing to the project. The maintainers of the project Saptak Sengupta, Niranjan Rajendran and Org admin Mario Behling were also very helpful and provided useful insights when solving the issues.

Time sure does move fast. I continued contributing to the project and in no time it was february. It was pretty late at night and I was just scrolling along my twitter feed when I noticed a tweet from fossasia announcing the winners of the Codeheat contest. Boy was I nervous !! I immediately clicked on the link and found out that I was among the grand prize winners. And all those nervousness was gone suddenly and I felt really happy and excited.

So I’m now planning to attend the fossasia summit (which is awwesommeee !!) in Singapore and hoping to meet new people, learn about new technologies and expand my horizons in the world of open source. I’m also looking forward to contribute more towards making this project a great success. Thanks Hong Phuc Dang, Mario Behling and fossasia for this wonderful opprtunity.