DEV Community: Ridhwana Khan

Reflecting on my journey in tech

Ridhwana Khan — Mon, 13 Mar 2023 08:18:41 +0000

Photo by Pixabay

As another year approaches and we celebrate individuals who are underrepresented and otherwise marginalized in software development, I took the time to reflect on my journey.

Back in March 2019, almost 4 years ago, I talked about my experiences as an underrepresented person in the tech industry and I shared the choices that I had made.

My experiences have evolved since I last discussed it as that young woman on stage. I feel safer, more confident and more hopeful about the future after working with companies like Forem that value equality in the workplace and continuously try to move the goal posts.

However, I still continue to practice those choices that I made many years ago:

To educate folks in the industry about the issues that we deal with as minorities.
To urge the people that I meet to be active participants in the struggle.
To mentor the next generation of leaders so that they are better equipped to deal with what’s thrown their way than I was, so that they may overcome these issues more easily and eventually eliminate them.
To speak up about these issues and create an awareness.
To surround myself with folks whom I can identify with and whom I can form a support system with.
To no longer doubt myself.

I still practice these choices everyday and I want to be reminded about them often so that I continue playing my part in helping to promote equality, diversity and inclusion in the tech industry.

Caching at DEV

Ridhwana Khan — Fri, 10 Feb 2023 13:15:06 +0000

We’ve always put a lot of effort into performance at DEV. We want our users to be able to see their content almost instantaneously when interacting with our content. In order to do so we’ve placed a big emphasis on caching. We’ve had to ask ourselves questions like what are the right things to cache? Which layer in the stack would be best to cache it? And how will this affect the overall performance?

As someone reading this post, you’re most likely a user of DEV 🙌🏼 which means that you know that DEV is a read-heavy site. Tens of thousands of users all around the world are reading content on our site at any point in the day. This content - for example, an article, once created will rarely change and so we can refer to it as “mostly” static content. There are also more interactive bits with DEV like being able to react to and comment on posts which provides us with interesting caching opportunities.

There are many types of caching that we apply in the application, however in this post we'll be discussing Response Caching specifically. At the core of our response caching strategy, we identify the static content and try to cache it so that users are not making a trip to our servers for each request.

Types of response caching on DEV

There are many types of response caching that occur in different layers of the application stack. One of the important decisions that you’ll make when developing features is to decide on which part of the stack you should implement caching.

💡 Do we implement caching to avoid hitting the origin server completely in the form of Edge caching?

💡 Do we implement caching at the view layer to reduce the number of database queries and complex rendering of the UI in the form of Fragment caching?

💡 Or do we implement Browser caching to constrict our request to never leave our browser?

Each of these strategies has different use cases and sometimes we may end up using a combination of multiple caching techniques on one feature to achieve the most optimised result.

Have you ever wondered why the article page on DEV loads up so quickly - even when the page is really long and there are tons of images it’s still pretty snappy! That’s mostly due to edge caching, and when the edge cache is being refreshed, you can thank Fragment caching for stepping in. The assets load pretty quickly on that page as well, we can thank the browser cache for caching our JavaScript and CSS for those pages.

Let’s go into more detail about each of these types of caching.

⚡️ Edge Caching

Edge Caching lives between the browser and the origin server, thus reducing the need to make a trip to the origin server for every request. Its where we add an intermediary storage (ideally closer to the user) between the user and the server to store the data for a period of time.

Why do we edge cache at DEV?

There are two parts of edge caching at DEV that make it beneficial for the application:

Edge caching moves memory storage closer to the end users by adding a machine ahead of the origin server. This means that a user from South Africa will get content served from a point of presence in Cape Town which contains the edge cache instead of going all the way to the origin server in the United States - the trip ends up being much faster.
The edge cache contains a cached version of the page that the user is requesting without having to do any re-computation thus making the response time really really fast.

Some of the benefits of the edge cache include reducing server load and stress on the origin server, improving content delivery and response times of requests thus reducing waiting time on web pages, and lightening the network load by reducing the amount of duplicate data.

At DEV we currently use Nginx or Fastly for our edge cache. In the future, we hope to allow for our configuration to be scalable enough to run through any caching intermediary.

Currently Fastly caches the content stored on our origin server at points of presence (POPs) around the world which then improves the user experience of our site.

Within our Fastly configuration we have shielding enabled. When one of Fastlys POPs is used as an "origin shield" it will reduce the load on the origin server. Thus, the requests to the origin will come from a single POP, thereby increasing the chances of an end user request resulting in a cache HIT.

How does edge caching actually work?

When a user navigates to our site https://dev.to/, they first hit our edge cache. Within this layer, the edge server will either have a warm cache or a cold cache.

Usually, the first visit to a site after a cache is set up or after it expires will reach a “cold” cache. A cold cache is an empty one that does not have any data stored. When a cache is “cold”, then the request will make its way to the origin server to retrieve the data, and it will be labeled a cache “MISS”. However, when it does this it also retains the data that it got from the origin server within the cache. This is referred to as the process of ‘warming’ the cache. A warm cache will contain data that is already stored and prepared to serve users. If the cache is warm, the data is returned from the cache to the browser and it will be labeled as a “HIT”. Every subsequent user will hit a warm cache until we expire or purge the cache and the same process repeats itself.

Expiring a cache

When caching objects it’s important to think about how long you want the cache to be around until it gets stale. One approach is to set a reasonably longer cache lifetime and then purge the cache on certain conditions

When we want our content to be edge cached we set the appropriate cache control headers. Here’s a snippet of the code that we use in the DEV codebase:



 before_action :set_cache_control_headers, only: %i[index show]

set_cache_control_headers is defined with the following configuration:



 def set_cache_control_headers(
   max_age = 1.day.to_i,
   surrogate_control: nil,
   stale_while_revalidate: nil,
   stale_if_error: 26_400
 )

   # Only public forems should be edge-cached based on current functionality.
   return unless Settings::UserExperience.public

   request.session_options[:skip] = true # no cookies

   RequestStore.store[:edge_caching_in_place] = true # To be observed downstream.

   response.headers["Cache-Control"] = "public, no-cache" # Used only by Fastly.
   response.headers["X-Accel-Expires"] = max_age.to_s # Used only by Nginx.
   response.headers["Surrogate-Control"] = surrogate_control.presence || build_surrogate_control(
     max_age, stale_while_revalidate: stale_while_revalidate, stale_if_error: stale_if_error
   )

The max-age header will help the edge cache server to calculate a Time To Live (TTL) for the cache. TTL is the maximum amount of time that the content will be used to respond to requests. Thereafter, the cache will need to be revalidated by consulting the origin server. TTL is defined in seconds. For DEV we set the default max-age to be 1 day, however, in some cases, we may override this value. We override this value for caching of the feed where we set the max-age to be two hours. I encourage you to grep for set_cache_control_headers in the codebase to explore the length of the caches for the various controller actions.

In case you’re curious about those other values in the snippet of code above:

stale-while-revalidate tells caches that they may continue to serve a response after it becomes stale for up to the specified number of seconds, provided that they work asynchronously in the background to fetch a new one.

stale-if-error tells the caches that they may continue to serve a response after it becomes stale for up to the specified number of seconds in the case where the check for a fresh one fails (in most cases where there is an issue at the origin server).

Some best practices worth outlining are that it is recommended to specify a short stale-while-revalidate and a longstale-if-error value. The Fastly docs rationale for recommending this is that if your origin is working, you don't want to subject users to content that is significantly out of date. But if your origin is down, you're probably much more willing to serve something old if the alternative is an error page.

Purging a cache

Expiring a cache allows a cache to be populated with fresh data periodically, however, there are times when you’d want to refresh the cache based on actions. This is where purging becomes useful. Purging describes the act of explicitly removing content from the edge cache, rather than allowing it to expire or to be evicted.

You’ve read above that we expire the cache on an article page after one day, but what if after publishing the article, the author realizes that they made some typos and they update the article? In this case, we wouldn’t want readers to continue viewing the outdated version with the typos. We’d want to “purge” that cache so that we can get the latest version from the origin server. Hence, when creating a cache you want to evaluate the conditions for which you’d need to purge the cache. In the case of the article page, we purge the cache on some of these actions below:

The above are some of the main cases where we purge the article, however, it is not the exhaustive list.

You can read more about Purging on the fastly developer documentation

Observing edge caching on DEV

We can observe edge caching on an article page on DEV.

When you load up a page like https://dev.to/devteam/top-7-featured-dev-posts-from-the-past-week-3id8, you’ll notice that the content of the article page loads really quickly but then the reactions take some time to come in. This is due to the fact that the first time we render the page, we hit an edge cache, and the article gets rendered from that cache. We then make a follow-up asynchronous request to get the reactions that are not needed immediately. From a user experience point of view, you’re most likely keeping your eye on the content to read the article before reacting to it. It's also useful to note that the comments are rendered along with the article on the first load, and this is mostly for SEO purposes.

In order to see whether a request is cached, you can click on the request in the network tab and look at the request headers. The request headers have an x-cache attribute which is written by Fastly which indicates whether the request was a HIT or a MISS. It also contains a header X-cache-hits which indicates the number of cache hits in each node.

These are useful headers to look out for to determine if the requests are being cached.

⚡️ Fragment Caching

Fragment Caching is used to cache parts of views, thus reducing the need to re-compute complex views

Why do we fragment cache at DEV?

In a typical Rails application, when a user visits a page on the site then a request to load the page would get sent to the Rails application. The application will then call the relevant controller which in turn will request the model for the data. The model fetches the data from the database and returns it to the controller. The controller, armed with the data, will render the view which is the user interface that you as a user will see on the web page.

However, that rendering can be slow for numerous reasons. Some of these include:

There can be expensive database queries in the view.
It may be a complex view with nested loops and we have tons of complex views at DEV.
There may also be many partials with some being nested which can increase rendering time.

Hence, to avoid the slowness that comes with the above problems, we sometimes cache the view to allow the request to complete more quickly.

How does fragment caching work?

Fragment caching removes the call to our Postgres database and reduces the time taken to compute a view in favor of storing the “fragment” in a memory cache (like Redis) as key-value objects. The key is provided within the Rails application and the fragment is stored as its value.

During the view rendering, if a cache key is come upon, it checks the Redis store for that cache key, if it finds the cache key, it reads the value of the cache key which is the Fragment, and renders it within the block. If it does not find the cache key, it will then compute the view, and write that key to the Redis store for next time.

Expiring a cache

A unique key is provided for every fragment that will be cached in our Rails view. Below is an example of one of our more complex cache keys that rely on numerous identifies :



<% cache("whole-comment-area-#{@article.id}-#{@article.last_comment_at}-#{@article.show_comments}-#{@discussion_lock&.updated_at}-#{@comments_order}-#{user_signed_in?}", expires_in: 2.hours) do %>
...

This view touches a few different resources, and hence you’ll notice the different dynamic aspects that make up the cache key. The cache key allows the cache to be purged each time it changes.

#{@article.id} requests that we maintain a cache of the comments section for every article page. #{@article.last_comment_at} will change when we add a new comment, and hence we’d want to refresh the cache. If a user chooses to not show the comments @article.show_comments or to lock a discussion thread discussion_lock&.updated_at, we want it to refresh the fragment cache as well. If a parameter is passed through that changes the sorting order of the comments #{@comments_order}.Finally we show a different view fragment for logged in vs logged out view.

When any of the above cache keys change then we’ll be writing to the Redis store.

Another way that we get fresh data is by expiring the cache. Just like with edge caching, we can set an expiry time after which the cache will be refreshed.

Observing fragment caching on DEV

We use fragment caching in numerous places on the DEV application, you can grep for <% cache in our codebase to view these instances. Some include:

These are just some of the instances where we use Fragment caching, and each of these views are cached for one of the reasons outlined above.

In order to observe Fragment caching you can run rails dev:cache. You can start off by clearing the cache with rake tmp:cache:clear to ensure that the first partial is rendered by the server. Thereafter, spin up the DEV server locally and navigate to the article page.

When you navigate to this page, you should be able to see the whole-comment-area... partial being logged.

On the first load when the cache is clear you will notice that we write to the cache



Cache write: views/articles/_full_comment_area:83798ee6f16a072196604860c4f72c64/whole-comment-area-9-2022-08-22 10:26:59 UTC-true--top-true ({:namespace=>nil, :compress=>true, :compress_threshold=>1024, :expires_in=>2 hours, :race_condition_ttl=>nil})
15:35:44 web.1       | [dd.env=development dd.service=rails-development dd.trace_id=781241634623167295 dd.span_id=0] Cache write: views/articles/show:136d4e5867aa13a4886bc993aba6558e/specific-article-extra-scripts-9-2022-12-19 14:55:37 UTC ({:namespace=>nil, :compress=>true, :compress_threshold=>1024, :expires_in=>24 hours, :race_condition_ttl=>nil})

However, on subsequent loads we’ll simply continue reading from the store.



15:28:44 web.1       | [dd.env=development dd.service=rails-development dd.trace_id=2192981961066220961 dd.span_id=0] Cache read: views/articles/_full_comment_area:83798ee6f16a072196604860c4f72c64/whole-comment-area-10-2023-01-25 13:02:56 UTC-true--top-true ({:namespace=>nil, :compress=>true, :compress_threshold=>1024, :expires_in=>2 hours, :race_condition_ttl=>nil})
15:28:44 web.1       | [dd.env=development dd.service=rails-development dd.trace_id=2192981961066220961 dd.span_id=0] Read fragment views/articles/_full_comment_area:83798ee6f16a072196604860c4f72c64/whole-comment-area-10-2023-01-25 13:02:56 UTC-true--top-true (0.4ms)

We realize that sometimes we may overuse Fragment caching at times in our application and there is probably some room for cleanup and improvement. One aspect to keep an eye on is the complexity of the cache keys. If the cache keys are more complex than the cached content then you may end up with a circumstance where it takes longer to check if there is a cache stored for that key in memory store than it does to render the view, then perhaps it's time to re-evaluate. Whilst Redis handles this very well and scales magnificently, sometimes the better path can be optimizing the database queries.

🪆 Russian Doll Caching

If you look through the application, we you will see that we sometimes nest the cached fragments inside other cached fragments - this is referred to as Russian Doll Caching. It ensures that our cached fragments are broken up into smaller pieces which allows the outer cache to be rendered faster when only one of the nested fragments change.

An example of Russian Doll Caching can be seen in the manner that we render our navigation links



 <%= render partial: "layouts/sidebar_nav_link", collection: NavigationLink.where(id: navigation_links[:other_nav_ids]).ordered, as: :link, cached: true %>

NavigationLink.where(id: navigation_links[:other_nav_ids]).ordered renders a navigation link collection. Hence, using the collection attribute, we’re theoretically wrapping each navigation link layouts/sidebar_nav_link partial in a cache block. Each object in the collection contains the details of a navigation link, and so if any of that data is updated, the cache of that particular element will be invalidated whilst the outer cache and the other nested caches will remain unchanged.

⚡️ Browser Caching

The Browser cache allows resources to be cached in one's browser, thus reducing the page load time and eliminating the need to go to the server. It stores resources in the web browser.

Why do we browser cache

At DEV we cache our static assets like images, CSS, and JavaScript. Previously, we had early adopted service workers as a form of browser caching but we later removed it when we ran into many caching bugs. We mainly browser cache to speed up the page loading process as well as minimize the load on the server.

How does the browser cache work?

When a user makes a request for the first time on a site, the browser will request those resources from the server and store some of the resources in the browser cache. On subsequent requests, these resources will then be returned from the browser instead of having to travel over the internet to the user.

In order to browser cache we set some headers in our production.rb:



 config.public_file_server.headers = {
   "Cache-Control" => "public, s-maxage=#{30.days.to_i}, max-age=#{3000.days.to_i}"
 }

Here, we are first setting the Cache-Control header to use public (intermediate) caching, for 3000 days with max-age. s-maxage stands for Surrogate cache, which is used to cache internally by Fastly. When the browser sees the above cache-control header it will cache the asset for a year, thus the network calls will no longer hit the server.

When the browser parses the index.html file it looks for the different referenced script files. You’ll notice that these files are fingerprinted. Hence the request for those files will look like https://dev.to/assets/base-bb53898178e7a6557807ce845d06cd2d60fd1e7ab108f2bad351d5bb92ec53b9.js. This versioning technique binds the name of a file to its content, usually by adding the file hash to the name.

If a file has been updated on the server, the fingerprint changes as well which then results in the browser not having a reference to that filename in its cache. Hence, it refreshes the cache for that resource.

Observing browser caching

From the screenshot below you can see that our js file returns a 200 (from memory cache) which shows that the response was indeed served from the cache. If you look at the Request Url you will notice that the file name is fingerprinted to let the browser know whether the resource has changed on the server or not.

Conclusion

To conclude, I’d like to discuss some of the questions I ponder on when trying to determine whether or not to implement caching on a feature.

One of them is “How often do we see the data for that feature changing?” If the answer to that is very seldom and “relatively static” then caching is most likely the way to go.

Another question that I ask is at what layer does it make sense to implement the caching? Here I think about what needs to be cached and how often will it need to be refreshed.

If I think that caching is the way to go then I explore whether it would be beneficial to implement only Fragment caching to cache any complex views on that page. Hence, allowing the requests to still hit the server but reduce the load on the database by serving from the application cache.

Or do I need something more, perhaps we anticipate a large load on the page, with successive hits from all around the world? In this case, edge caching will be more efficient in serving the page. Maybe it makes sense to do both, like we do in many parts of the DEV application.

There’s no right or wrong answer here, but as with all performance problems, we encourage our team members and contributors to analyze the problem carefully and run some tests in order to make the most informed decision.

And that’s all folks - I hope that you found this post useful. Please drop any feedback and comments below 👇🏽.

Documenting Forem's v1 API

Ridhwana Khan — Thu, 19 Jan 2023 15:53:29 +0000

Forem has set a milestone to update our (v1) API documentation and we need YOUR help!

There are several endpoints that we would like to document in order to complete our v0 -> v1 upgrade. v0 will eventually be deprecated and removed (there aren't any breaking changes so existing endpoints will continue to work the same as before). If you’re looking to contribute to open source, these are awesome first issues to work on and this post will help guide you through them.

In this post, I’ll outline the details about our v1 API, we’ll discuss its documentation and then I’ll walk you through an example of an API endpoint that I had recently documented.

About the v1 API

The API is a REST (REpresentational State Transfer) API, which means that it follows a set of guiding principles that you can read more about here.

There are currently many resources that can be accessed via the API, however, it does not contain all of the resources that we have available on DEV. We are continuously adding more endpoints to the API.

It is important to note that all operations are scoped to a user at the moment, and one cannot interact with the API as an organization.

Headers

The API consists of both authenticated and non-authenticated endpoints.

Most read endpoints do not require authentication and can be accessed without API keys. However, we require authentication for most endpoints that can create, update or delete resources, and those that contain more private information.

CORS (Cross Origin Resource Sharing) is disabled on authenticated endpoints, however endpoints that do not require authentication have an open CORS Policy. With an open CORS policy you are able to access some endpoints from within a browser script without needing to connect via a server or backend.

Authentication is granted via a valid API Key. The API key can be generated by logging into your account at dev.to and clicking on Generate API Key on the Settings (Extensions) page.

Once you’ve generated your API key, you are ready to start interacting with the API. The API Key will be set as a header, namely api-key, on a request.

We require another header for accessing the v1 API - the Accept header. The Accept header needs to be set to application/vnd.forem.api-v1+json, where v1 is the version of the API. If you do not pass along an Accept header you will automatically be routed to v0 of the API. API (v0) will be deprecated soon and we encourage you to rather use v1.

Accessing the API

As mentioned above, there are some API endpoints that are authenticated and others that do not require authentication.

When interacting with an endpoint that does not require authentication, you can pass through a single header (the Accept header) that will set the version of the API that you are interacting with.

curl -X GET https://dev.to/api/articles\?page\=1 --header "accept: application/vnd.forem.api-v1+json"

An endpoint that requires authentication would need both the Accept and the api-key header to be set when making the request:

curl -X PUT http: //localhost :3000/api/users/1/unpublish
--header "api-key: <your-api-key>"
--header "accept: application/vnd.forem.api-v1+json" -V

You need to have the correct roles and permissions set on your user to be able to query certain data from the API. For example, only admins can read, create, update and delete Display Ad resources.

About our documentation

Our v1 API endpoints are documented according to the OpenAPI Specification.

The OpenAPI Specification

The OpenAPI Specification (previously known as a Swagger Specification) is a standard for defining RESTful interfaces. As per the definition on their website, it is a document (or set of documents) that defines or describes an API.

An OpenAPI definition uses and conforms to the OpenAPI Specification. The OpenAPI definition can be created within your codebase.

You can view the Open API Specification here. It describes API Versions, Formats, Document Structure, Data Types, Schemas and much more.

When an API adheres to the Open API specification, it allows opportunities to use document generation tools to display the API, code generation tools to generate servers and clients in various programming languages, access to testing tools etc. Some of these tools include Swagger UI, Redoc, DapperDox and RapidDoc.

Forem, which is a Ruby on Rails app, integrates the Open API Specification via a gem - the rswag gem. The rswag Ruby gem allows us to create a DSL for describing and testing our API operations. It also extends rspec-rails "request specs", hence, allowing our documentation to be a part of our test suite which allows us to make requests with test parameters and seed data that invoke different response codes. As a result, we are able to test what the requests and responses look like, however we do not test the business logic that drives the endpoint - that is tested elsewhere in the code.

Once we write the test, we are able to generate a JSON file that conforms to the Open API Specification thus allowing us to eventually use the document generation tools to format and beautify our documentation.

The OpenAPI definition in the form of api_v1.json is generated and used as input to Docusaurus to create our documentation. You can view our v1 documentation here.

Now that we’ve discussed how Open API and rswag fit together to create the API documentation let’s work through an example of adding documentation to an endpoint together.

Documenting a v1 endpoint

We’ll be working on this github issue together. The issue outlines a task to use rswag to document the /api/followers/users endpoint in the v1 API.

For reference, our v1 documentation lives here.

There is also a pull request for the code written in the example below which you can reference.

Skeleton

Let’s start by creating a file for the endpoint that we want to test and document.We can go ahead and create spec/requests/api/v1/docs/followers_spec.rb

There are some building blocks for each test - a skeleton that defines some standards, implementation details like generating the header values, seed data etc.

Below is a code snippet of the skeleton for this test:

require "rails_helper"
require "swagger_helper"

# rubocop:disable RSpec/EmptyExampleGroup
# rubocop:disable RSpec/VariableName

RSpec.describe "Api::V1::Docs::Followers" do
 let(:Accept) { "application/vnd.forem.api-v1+json" }
 let(:api_secret) { create(:api_secret) }
 let(:user) { api_secret.user }
 let(:follower1) { create(:user) }
 let(:follower2) { create(:user) }

 before do
   follower1.follow(user)
   follower2.follow(user)
   user.reload
 end

 describe "GET /followers/users" do
   path "/api/followers/users" do
     get "Followers" do
     end
   end
 end
end

# rubocop:enable RSpec/EmptyExampleGroup
# rubocop:enable RSpec/VariableName

We start off by importing the necessary libraries - in this case the rails_helper and the swagger_helper that will allow us to use the DSL to build out our definitions.

If you’re use RSpec before then the describe block will be familiar to you, it will create an example group.

let(:Accept) { "application/vnd.forem.api-v1+json" }
let(:api_secret) { create(:api_secret) }

Above, we define (but not yet set) the header values. The accept header will allow us to access the v1 API and since the /api/followers/users endpoint requires authentication we generate an API secret that we will use later on.

let(:user) { api_secret.user }
let(:follower1) { create(:user) }
let(:follower2) { create(:user) }

 before do
   follower1.follow(user)
   follower2.follow(user)
   user.reload
 end

Above, we use RSpec to setup our data so that we can have example responses in our API documentation. We create a user and two follower users. With these models in the DB rswag will run the tests and display the example tags created by FactoryBot in the json file. In the before block, we then setup the two follows to follow the user.

describe "GET /followers/users" do
   path "/api/followers/users" do
     get "Followers" do
     end
   end
end

In a nested describe block we start by specifying the path for the endpoint that we’re testing which is /api/followers/users. You can read more about path operations in the rswag documentation.

In some circumstances, you may have an identifier or parameter in the path. These are surrounded by curly braces. For example: /api/articles/{id}.

Operation Ids

get "Followers" do
end

The above is considered our operation block. In this instance we define that we are implementing a GET.

The Operation Object has several fields that can be set to help define this endpoint. You can read more about operation objects here.

These are some of the fields that we want to define for api/followers/users:

get "Followers" do
  tags "followers"
  description(<<-DESCRIBE.strip)
  This endpoint allows the client to retrieve a list of the followers they have.
  "Followers" are users that are following other users on the website.
  It supports pagination, each page will contain 80 followers by default.
  DESCRIBE
  operationId "getFollowers"
  produces "application/json"
end

Below, I’ve taken some of the definitions from the specification and applied it to the code sample to help explain what each field does.

tags: A list of tags for API documentation control. They are used for logical grouping of operations by resources or any other qualifier. In this case, we want this endpoint to be grouped on its own and so we provide it with a new tag. In other circumstances, you may want to tag your crud operations for a single resource all with the same tag so that they can logically group together.

description: Provides a verbose explanation of the operation behavior. CommonMark syntax may be used for rich text representation. We try to describe what the endpoint does in a single sentence. Thereafter, we can provide additional context that we think will be useful to the user of the API at a glance.

operationId: This is a unique string used to identify the operation. The id must be unique among all operations described in the API. The operationId value is case-sensitive. Tools and libraries may use the operationId to uniquely identify an operation, therefore, it is recommended to follow common programming naming conventions. We try to structure the work with the CRUD operation as the prefix and the resource as the suffix.

produces: This field populates the response content type with the produces property of the OpenAPI definition. Our response type is usually JSON.

Another noteworthy field that we add to other endpoints but is not relevant to this particular endpoint is:

security: This is a declaration of which security mechanisms can be used across the API. Individual operations can override this definition.

We define a security scheme globally in swagger_helper.rb levelsecurity: [{ "api-key": [] }],. The security scheme that we utilize applies authentication via an api-key header.

However, remember earlier I mentioned that not all endpoints need authentication. Hence, for those that do not need authentication, we can override the "security" attribute at the operation level. To do this, we provide an empty security requirement ({}) to the array.

If you look at /api/articles in the article_spec you will see security [] which indicates that this endpoint does not need authentication.

However, in the case of the endpoint that we’re documenting /api/followers/users we do not need to provide a security field as we’ll use the one that is defined globally with the API key for authentication via an api key.

Now that we’ve set these operationIds, let’s have a look at how they would get generated in the JSON file.

The operationIds set the scene for how the API operates. Next, we’ll want to define the parameters that the API endpoint allows.

The following two sections, Parameters and Response Blocks, rely on schemas, so before we get into the details of these sections let’s first discuss what a schema is.

The OpenAPI Specification allows you to describe something called a "schema" which in its simplest form refers to some JSON structure. These can be defined either inline with your operation descriptions OR as referenced globals.

You can use a referenced global when you have a repeating schema in multiple operation specs. For example, an article resource may be returned in a create, read or update, hence instead of repeating this JSON across all these operations you could add it as a referenced global in the swagger_heper.rb and then use that $ref.

The global definitions section lets you define common data structures used in your API. They can be referenced via $ref: "a schema object" – both for request body and response body.

Another instance where you may want to use a referenced global is when multiple endpoints accept the same parameter schema and you do not want to repeat this JSON for multiple endpoints.

Parameters

If you look at the code for the api/followers/users endpoint, you’ll notice that it takes three optional parameters; page, per_page and sort.

You’ll notice that we use page and per_page across multiple endpoints for our pagination strategy hence that reusability makes it the ideal candidate for a referenced global.

Since it’s been used before, you’ll find it defined globally in the swagger_helper.rb. Hence, all we need to do is reference it in our spec.

parameter "$ref": "#/components/parameters/pageParam"
parameter "$ref": "#/components/parameters/perPageParam30to1000"

However, our next parameter - sort, has not been defined before and does not seem to be re-used in the same manner across any existing endpoints. Thus we can define it inline.

    parameter name: :sort, in: :query, required: false,
              description: "Default is 'created_at'. Specifies the sort order for the created_at param of the follow
                               relationship. To sort by newest followers first (descending order) specify
                               ?sort=-created_at.",
              schema: { type: :string },
              example: "created_at"

You can read more about describing query parameters in the OpenAPI Guide here

This is what the final set of query parameters look like:

get "Followers" do
  ......
  parameter "$ref": "#/components/parameters/pageParam"
  parameter "$ref": "#/components/parameters/perPageParam30to1000"
  parameter name: :sort, in: :query, required: false,
            description: "Default is 'created_at'. Specifies the sort order for the created_at param of the follow
                               relationship. To sort by newest followers first (descending order) specify
                               ?sort=-created_at.",
            schema: { type: :string },
            example: "created_at"
end

And this is what the corresponding generated JSON would look like:

Response Blocks

Once we’ve defined the operation Ids and Parameters, we can define what the response query looks like. We can create multiple response blocks in order to test the various responses a user of the API may receive. This includes testing when the API endpoint provides a response, when there is no content, when the user is not authorized etc.

In this case, we’ll test what a successful response looks like and what an unauthorized response looks like when we do not provide the correct api-key.

A successful response with status code 200

response "200", "A List of followers" do
  let(:"api-key") { api_secret.secret }
  schema type: :array,
         items: {
           description: "A user (follower)",
           type: "object",
           properties: {
             type_of: { description: "user_follower by default", type: :string },
             id: { type: :integer, format: :int32 },
             user_id: { description: "The follower's user id", type: :integer, format: :int32 },
             name: { description: "The follower's name", type: :string },
             path: { description: "A path to the follower's profile", type: :string },
             profile_image: { description: "Profile image (640x640)", type: :string }
             }
   add_examples


   run_test!
end

The HTTP 200 OK success status response code indicates that the request has succeeded.

In order for the request to succeed, we first need to provide the necessary authentication. When this example runs, it will need the api-key for authentication, hence we set it in our RSpec test.

In this case, I’ve decided to define the schema object inline because it is a uniquely structured response that is not being shared with other endpoints. However, if more than one endpoint had the same schema it would have been beneficial to define it globally in the swagger_helper and then provide a reference to it in the various spec files.

  schema type: :array,
         items: {
           description: "A user (follower)",
           type: "object",
           properties: {
             type_of: { description: "user_follower by default", type: :string },
             id: { type: :integer, format: :int32 },
             user_id: { description: "The follower's user id", type: :integer, format: :int32 },
             name: { description: "The follower's name", type: :string },
             path: { description: "A path to the follower's profile", type: :string },
             profile_image: { description: "Profile image (640x640)", type: :string }
          }
        }

The schema that we have defined above is an array of objects. The top level type is defined by an array type and each item is an object. Thereafter, we further define the properties that can be expected in each object. We advise that a description for a property is added where necessary.

If the need to re-use the schema object for multiple endpoints arose, we could have defined it as a Follower in the swagger_helper.spec and then referenced it in our spec like below:

schema type: :array,
        items: { "$ref": "#/components/schemas/Follower" }

The add_examples method can be found in the swagger_helper and it is responsible for creating the Response Object.

It creates a map containing descriptions of potential response payloads.
The key is a media type or media type range like application/json and the value describes it.

Finally, the run_test! method is called within each response block. This tells rswag to create and execute a corresponding example. It builds and submits a request based on parameter descriptions and corresponding values that have been provided using the rspec "let" syntax. In order for our examples to add value, we want to give it a good set of seed data.

If you want to do additional validation on the response, you can pass a block to the run_test! method.

You can read more about how to use run_test! from the rswag documentation.

An unauthorized response with status code 401

response "401", "unauthorized" do
  let(:"api-key") { nil }
  add_examples

  run_test!
end

The HyperText Transfer Protocol (HTTP) 401 Unauthorized response status code indicates that the client request has not been completed because it lacks valid authentication credentials for the requested resource. Hence, in this case if we provide an invalid api key, we should expect a 401.

To test this case, we simply provide an invalid API key which will not allow us to authenticate to the API.

The generated JSON for these two responses look as follows:

Generating the JSON

I’ve been referencing the JSON files above, but you must be wondering how do you access that JSON. Once you have written your spec, you can generate the JSON file for the API by running

SWAGGER_DRY_RUN=0 RAILS_ENV=test rails rswag PATTERN="spec/requests/api/v1/**/*_spec.rb"

Once you do this, you will see a newly generate file at https://github.com/forem/forem/blob/main/swagger/v1/api_v1.json.

Take the time to evaluate the generated content in this file, especially for the new spec. In order to view it you may paste the JSON into https://editor.swagger.io/. When you do this, it will display the data as documentation and also let you know if there are any errors.

If you have Visual Studio Code, we suggest you install the following extensions that enable validation and navigation within the spec file:

And that, my friends, is how we document API v1 endpoints at Forem.

You can find the code for this example here.

If you have any questions or feedback, please drop them in the comments below. If you’d like to contribute to our documentation please have a look through the ones that aren’t assigned in this milestone and raise your hand on the issue. We look forward to your contributions.

Destructuring in Ruby

Ridhwana Khan — Wed, 03 Aug 2022 09:46:00 +0000

Destructuring refers to the process of unpacking a small part of something from the main part. In Ruby, we use destructuring to conveniently extract multiple values from data stored in Arrays or Hashes. It provides a way for us to group or ungroup data and assign them to variables where needed.

In this article we’re going to discuss destructuring for assignments, arrays and keyword args. We’ll also touch on why you would utilize destructuring.

The most straightforward form of destructuring is through multiple assignments. This form of destructuring assigns the variables on the left to the values on the right in the order that they are provided.

As an example:



a, b, c = 1, 2, 3

a => 1 
b => 2 
c => 3

In the above example the variables on the left are assigned to the values on the right. If we have a mismatch between the number of variables ready for assignment on the left and the number of values on the right then some of the variables will remain unassigned like below:



a, b, c, d = 1, 2, 3

a => 1 
b => 2 
c => 3 
d =>  undefined local variable or method `d' for main:Object
```

If we have a mismatch in the number of values on the left, with fewer variables to assign to them, then some of the values will remain unassigned like below: 

```ruby
a, b, c = 1, 2, 3, 4

a => 1 
b => 2 
c => 3 
```

More complex destructuring can be done using an operator in Ruby called the the splat (*) operator. Splat performs different operations depending on how it is used, let’s discuss how splat works. 

## Slurp/Collect

When the splat operator appears on the left hand side of an assignment then we can refer to the operation as slurp or collect. Slurping takes a variable number of values and collects it into an array.

The example below with a *slurp on a variable at the end* will collect the rest of the values (into an array) that have not been assigned to the first two variables: 

```ruby
a, b, *c = 1, 2, 3, 4

a => 1 
b => 2 
c => [3, 4]
```

Splat is pretty smart - it can slurp up the “rest” of the values depending where the splat operator is positioned. Let’s look at some more examples.

```ruby
a, *b, c = 1, 2, 3, 4

a => 1 
b => [2, 3] 
c => 4
```

A splat operator *somewhere in the middle* will get the “rest” of the values once the other non-splatted variables are assigned. In this case, `a` gets assigned to the first value, then `c` gets assigned to the last value and `b` gets assigned the remainder of the values in the form of an array. 

Now, think about what you would expect a *slurp operator on a  variable at the start* of the assignment to yield?

```ruby
*a, b, c = 1, 2, 3, 4
```

Well, we’d look at the non splatted values first and work our way backwards - `c` will take the value of 4, `b` will take the value of 3 and `a` would collect the “rest” of the values into an array i.e. `[1, 2]`. Does that make sense to you? 

Just like above, an array can also be destructured into multiple parts and assigned to variables.

```ruby
a, *b, c = [1, 2, 3, 4, 5]
a => 1
b => [2, 3, 4]
c => 5
```

## Split

Up until now we talked about a splat on the left hand side of the assignment which slurps or collects up the values on the right hand side. How does it then work when the splat operator (*) is on the right hand side? It will split up the array into individual components. 

```ruby
list = [2, 3, 4]

a, b, c  = 1, *list 
```

Destructuring on the right hand side allows us to split the collection into a list of values being assigned. 

So in the case above the splat on `*list` will change the statement into:

```ruby
a, b, c  = 1, 2, 3, 4
```

and so the assignments happen as per usual: 

```ruby
a => 1
b => 2
c => 3
```

Let’s look at a more complex example - what if we had to split on the right side of the assignment and slurp up values on the left side, how would that work?

## Slurp and Split

```ruby
array =  [2, 3, 4, 5]

a, *b, c = 1, *array
```

You’re already equipped with the tools for dealing with them separately so let’s apply that knowledge. 

First, let’s look at the right side of this assignment. Based on previous knowledge we know that the splat operator on the right hand side will split, meaning that it will convert the array into a list of values like below: 

```ruby
array =  [2, 3, 4, 5]

a, *b, c = 1, 2, 3, 4, 5 
```

Now that we’ve done that, let's look at the left hand side of the assignment. As per the rules that we learned earlier, we will allocate the first variable `a` to the first value `1`. We have the splat in the middle so let's leave that for last. We then allocate out the last variable to the last value, so `c` is assigned to `5`. Finally, we’ll focus on the splat operator which indicates that we should slurp up the rest of the values `[2, 3, 4]` to assign to `b`.

## Implicit and Explicit Splats

If we have an assignment containing just one variable on the left with a number of values on the right, it will slurp up all of the values into a new array.

```ruby
a = 1, 2, 3, 4

a => [1, 2, 3, 4] 
```
This is equivalent to 

```ruby
a* = 1, 2, 3, 4

a => [1, 2, 3, 4] 
```

Notice that in the first example we didn’t need the asterisk, the value was just *implicitly spatted*. In some cases where the assignments are more straightforward, this is acceptable.  

However, if you wanted to perform destructuring where there is more than one variable on the left you would need to explicitly splat the variable. You would also have noticed in some of the above sections that there are cases whereby an array will be listed alongside individual values, and hence you would need an explicit splat to break down the array into its component values.

## Keyword Arguments 

In a rails app you’ll often come across a splat on argument methods, like `*args` below:

```ruby
def say_hello(name, *args)
 puts "hello #{name}"
 args.each do |arg|
   puts "hello #{arg}"
  end
end

say_hello("Goofy", "Donald Duck", "Fred Flinstone", "Pluto")

=> hello Goofy
=> hello Donald Duck
=> hello Fred Flinstone
=> hello Pluto
```

Abiding to our previous rules outlined, the splat operator on `*args`  collects the rest of the parameters except the one assigned to `name`. It then converts those “rest” of the arguments to an array within the method, hence, allowing us to loop through the args.

In this manner, we don’t need to specify the number of arguments that we are providing to the method. Instead, we can deal with them as an array that we loop through.

The parameter with the splat operator is also optional, which means that if we omit these arguments to a method, Ruby will not complain about it. 

```ruby
say_hello("Goofy", "Donald Duck", "Fred Flinstone", "Pluto")

=> hello Goofy
=> []
```

It is important to note that a method cannot have two parameters with a splat operator, and you can only splat the last parameter to a method. 

Now that we’ve got a good foundation on how destructuring is used, let’s talk about when we would use destructuring.

## Use Cases

Destructuring can be used: 
- When you do not want to specify the number of parameters that you have.
- When you want to make the parameter optional - a parameter with a splat operator is optional. 
- When you’d like to convert a list of arguments to an array within the method and vice versa - when you want to convert an array into several arguments.. 
- You can use destructuring when programming in a functional, recursive manner whereby you can assign the first parameter to one variable and the rest of the variables can be assigned to another variable using a splat. 

The scenarios above are only some instances where destructuring can be useful, let me know how you’ve used destructuring in the past.


![Cut a slice of cake gif](https://media.giphy.com/media/xUPGcCM0nd2A4sIuaY/giphy.gif)

Getting Oriented with Objects in Ruby

Ridhwana Khan — Wed, 08 Jun 2022 17:06:55 +0000

This post is co-authored by @juliannatetreault and @ridhwana.

In our last post we briefly touched upon a few topics such as: object orientation, dynamic languages and memory management. However, we barely scratched the surface of these concepts, and so in this post, we’d like to dive deeper into object orientation and how it all comes together in Ruby.

Ruby Objects

As we mentioned in our previous post, Ruby is centered around the concept of “objects”. Everything in Ruby is an object - this includes Booleans, Strings, Integers and more.

A Ruby Object will contain its own set of attributes, which you can think of as data, and its own set of methods, which you can think of as the behaviour.

Ruby Objects communicate by sending messages to each other. These messages can be thought of as instructions. When we talk about “sending a message from Object A to Object B”, what we actually mean is that we “call or invoke a method on Object B”. These terms can be used interchangeably.

If you take a second to look up from reading this article and glance around your surroundings, you’ll see that there are objects everywhere in the world.

As I look up at this moment, I see - my 😼, a 🪴, a 📘, a 🖨 and a 🛋 are some of the objects that jump out to me. All of these have the potential to be modelled as Objects each with its own data and behaviour, and sometimes these objects send messages to each other, like when my cat chews on a leaf from my plant.

Some of the concepts that we’ll need to discuss first before fully understanding Ruby objects are classes, attributes and methods.

What is a Class?

A Class is a blueprint for the construction of similar objects - you can think of it as a template that we use to create objects. The template provides the set of attributes and methods for an object, which will then help each object to define its own set of data and shared behaviour.

For example, we may want to represent my cat. In order to do this, we’d first create a blueprint that we could use to represent all cats.

Below we represent the Class-y Cat, haha get it?

This blueprint will contain the attributes that a cat may have like name, age, colour and weight. It will also contain behaviour like the sound that a cat will make or how it will move its tail. In the future, we may want our blueprint to be more general, so we may want to make an Animal blueprint and use it to create both a cat and a dog object - but that’s for later.

In reality, the code for the Cat Class may look something like this:

class Cat 
  def initialize(name, age, colour, weight)
    @name = name
    @age = age
    @colour = colour
    @weight = weight
  end

  def make_sound()
    return "meow"
  end

  def move_tail()
   return "twitching"
  end 
end

In order to describe my cat, we would use this template to instantiate a new object. In Ruby the new method is used for instantiating an object. This now creates my object as an instance of the Cat Class.

zeus = Cat.new("Zeus", 2, "brown", 5)

Now this may not make sense to you as yet, but let’s break down the code above by describing the attributes and methods.

Attributes (Data)

name, age, colour and weight in the parenthesis are referred to as parameters. They describe the characteristics of the object.

When we instantiate an object, like in the code below, we pass through the values for these parameters in the form of arguments. The arguments are what allow us to provide specific values for that object.

When we call the method new on a class, the class will create a new instance of itself. Internally, it then calls the method initialize on the new object, and it will pass all the arguments to the method initialize.

The initialize method as outlined in the image above is then responsible for preparing the instance data for the object. @name, @age, @color and @weight are referred to as instance variables - they can be identified by the @ prefix. Instance variable data is unique to the object.

Instance variables by default cannot be accessed from outside the object:

zeus = Cat.new(“Zeus”, 2, “brown”, 5)  
zeus.age
=> NoMethodError: undefined method `age`

But what if we really need to print out Zeus’s age from outside?

Well, there are definitely times when we may want to access (read and write) these instance variables from the outside. In these cases we can access the attributes with attribute accessors.

There are three attribute accessors that we will discuss:

attribute_reader

In order to be able to read an attribute from the outside without the need to change it then you can use an attribute_reader.

class Cat
  attribute_reader :age

  // rest of the code
end

When you add attribute_reader to your code, Ruby then creates a method on your behalf that looks like the code below, and allows you to read the attribute. The symbol for the attribute_reader is used as the name for this getter_method as defined below.

class Cat
  def age
    @age
  end
  // rest of the code
end

zeus = Cat.new(“Zeus”, 2, “brown”, 5)  
zeus.age
=> 2

You’ll learn more about methods in the next section.

attribute_writer

Likewise, in order to be able to write to an attribute from the outside then you can use an attribute_writer. Just like with attribute_reader Ruby then creates a method on your behalf that looks like the code below, and allows you to write to the attribute.

class Cat
  def age=(value)
    @age = value
  end
end

zeus = Cat.new(“Zeus”, 2, “brown”, 5)  
Zeus.age = 4

attribute_accessor

In order to be able to both read and write to an attribute, we would use attr_accesor. Ruby then creates both methods on your behalf.

Now that we’ve discussed attributes, let’s talk about methods.

Behaviour (Methods)

Methods allow you to bundle code that can perform tasks and return results in a named, DRY (don’t repeat yourself!) way. Methods can be called from other code, allowing programmers to use the bundled code without having to rewrite it in every place it’s needed.

When it comes to crafting a method, there are a few things you should know about them:

First, methods are defined using the def and end keywords. def, followed by a name, represents the start of a method. The end keyword does just that – it ends the method. What comes in between the def and end keywords is the bundled code or logic.

def method_name
   // insert some behaviour here 
end

Next, methods have their own set of naming conventions. When creating a method, it is important to keep these naming conventions in mind, as it’ll make it easier to understand the intent of the method for the next programmer (or you, 6 months down the road!). The naming conventions we’d like to draw your attention to are: naming your method, the capitalization of your method, and what to do when your method name is longer than a single word.

Let’s begin with naming your method. When brainstorming method name ideas, it is important to ensure that the method is aptly named – the method’s name should be explanatory, giving insight into the method’s purpose. If you’re creating a method that will give your Cat Object the ability to meow, then naming the method meow is a good place to start. Now let’s touch upon method capitalization, or the lack thereof. Method names should consist of all lowercase letters. Finally, let’s discuss what to do when your method name is longer than a single word. Multi-word method names in Ruby are written in snake case. For example, if you had a method that both made your Cat Object meow and move its tail, you might write it as meow_and_move_tail, where the underscores between each word represent snake casing.

def meow_and_move_tail
   // insert some behaviour here 
end

Finally, the logic within a method is always indented. The rule of thumb when it comes to indentation is four spaces or a tab to the right. While there is an ongoing feud within the programming community about which approach is right (hint: neither are!), it all boils down to preference.

Tabs or spaces - which side are you on?

On the topic of crafting methods, one thing that is important to mention is that methods can accept default arguments and values, which can level up your method and make it more reusable. A default argument allows a method to be called with or without the provided argument, allowing for flexibility. It also gives you the option to reassign the value passed to the default argument, making the method more extensible. To pass a method a default argument with an assigned value, open a set of parentheses after the method name and define the argument and its value like so:

def make_sound(sound = “Meow”)
  // insert some behaviour here 
end

In the above make_sound method, we pass a default argument sound, with the value meow. By passing this default argument, if we were to lean on the default argument in the method’s logic, we could expect that the string “Meow” would be returned whenever the method is called.

def make_sound(sound = “Meow”)
  puts “#{sound}!”
end

Now you may be wondering what those squiggly brackets and hashtag are doing within the make_sound method–the use of this is called string interpolation, which can briefly be explained as embedding the value within the string that it is a part of. This is something we may touch upon in a later post, so stay tuned, folks!

Similar to default arguments, methods can also accept required parameters. While default arguments and values are optional, required parameters are just that - required. Just like default arguments, required parameters are defined within a set of parentheses that come right after a method’s name. Unlike default arguments though, a required parameter is not given a default value, rather its value is defined when the method is invoked.

def make_sound(sound)
  puts “#{sound}!”
end

make_sound(“Purr”)

So, method naming conventions, default arguments, and string interpolation aside, let’s briefly touch upon CRUD actions, or the widely used methods standard to Ruby. CRUD, which stands for create, read, update, and delete, are a set of methods provided in Ruby that perform basic actions such as creating, reading, updating, or deleting an Object. These methods are important to recognize due to their wide use.

Now, with all of this new-found knowledge of methods, you may be wondering how to actually make use of this behaviour. If so, then this paragraph is for you! We refer to making use of a method’s behaviour as “invoking” or “calling” a method in Ruby. This can be accomplished using dot notation, which when used, invokes a method, passing along a message to an Object, which in our case, is our Cat, Zeus.

Is that really all there is to methods?! Seems pretty straightforward to me…

The above is just the beginning and while there is so much more to learn about methods, knowing the above should get you to a good baseline understanding of how Objects are given behaviour and receive messages through methods. If you’re keen to dive a bit deeper though, we’ll be releasing a brief follow up post that will touch upon some of the topics that didn’t make it into this post.

And that’s it folks…

Credits to @juliannatetreault for the adorable cat drawings.

Introducing Rediscovering Ruby

Ridhwana Khan — Mon, 23 May 2022 16:38:35 +0000

This post is co-authored by @juliannatetreault and @ridhwana.

Introduction

👋 Hi there and welcome to the first post in our series, Rediscovering Ruby.

My name is Julianna. I’m a primarily backend-focused Software Engineer at Forem and I have been working with Ruby and Rails, almost exclusively, for roughly 3 years now and I still learn new things about Ruby almost daily.

My name is Ridhwana and I’m a Full Stack Lead Software engineer at Forem. I’ve been dabbling in Ruby on Rails for about 8-10 years and spent just under half of that time focussing on backend development which has been leading me through weird and wonderful explorations in this language.

Why are we writing this series?

We’ve been working together for a while now and thoroughly enjoy it. We often find ourselves talking through Ruby concepts or pair programming asynchronously through pull request reviews. We’ve realized that a lot of developers (including ourselves) end up learning a new language by exploring and copying existing patterns within an already existing codebase. This sometimes leaves us without a name for a pattern that we’re following or without a deeper understanding of what's happening behind the “magic” of the language. It also means that sometimes we struggle to articulate concepts that we use on a daily basis.

Hence, we came up with an idea to write a series of posts that explore and explain these different concepts in Ruby. We hope that you’ll follow along and share your knowledge and experiences with us too.

What do we plan on covering in this series?

First, we’ll begin with the basics–foundational concepts and the like. While the rest of our plan is still a bit up in the air, after covering some of the core Ruby concepts, we plan to slowly start introducing more complex topics. Some of the concepts and topics that we hope to cover include: classes, objects, memory, and duck-typing.

With that being said, let's dive into an introduction of our favourite language Ruby.

About Ruby

Ruby was conceived in 1993 and publicly released in 1995 by its creator Yukihiro “Matz” Matsumoto. It's approximately ~27 years old already!

Over the years, Matz, Ruby’s creator, can be found talking about some of his motivations for creating Ruby. Some of these include:

Blending parts of his favorite languages at the time like Perl, Smalltalk, Ada and Lisp etc. into a better object-oriented version, Ruby.
In a Google talk in 2008 he told the audience that he hoped to see Ruby help every programmer in the world to be productive, and to enjoy programming, and to be happy. He also jokes that he created Ruby for selfish reasons because he was so underwhelmed by other languages that he just wanted to create something that would make him happy.

Shortly after the release of Ruby, interest in the language quickly grew in Japan. In 2000, the first English-language book “Programming Ruby” was released by author Dave Thomas. This helped to spread the language internationally, and by 2006 Ruby had become popular worldwide. However, after the release of the Ruby on Rails framework the community grew even bigger.

The Ruby Community

As mentioned above, Ruby has been around for a while, and so has the community that supports the language. The Ruby community has a reputation for being welcoming and supportive, which is one of the reasons why the language is often suggested for beginners.

If conferences or meetups are your thing (or if you’d like them to be!), Ruby has a plethora of in-person and more recently, remote events. Additionally, due to the age of the language and the size of the community, there are many opportunities to contribute to Open Source projects that use Ruby as their foundation and there are many learning resources available (like this one! :)) for when you want to better acquaint yourself with the language’s intricacies.

A Ruby Primer

Ruby can be described as “Object Oriented and Dynamic language.”

What exactly does object oriented mean?

This means the language is centered around the concept of “objects.” Hence, in order to write useful applications in an OO language, the code will contain a group of objects. Each object will have its own set of attributes and methods, and these objects will send and react to messages from the other objects. .

In order to understand what is a “dynamic language'' let's get two definitions out of the way - compile time and run-time?

Compile-time is the time at which the source code is converted into an executable code.
Run time is the time at which the executable code has started running.

Knowing the above, what does this have to do with a dynamic language?

Well, a dynamic language gives us the ability to carry out certain actions at runtime that other languages cannot, such as assigning and reassigning objects without running into compiler-related issues.

In addition, if any errors occur during compile-time, the process will not be halted by those errors and will continue to move forward. For example: If we were to call a method on an object that does not exist, the compiler will not produce a warning or an error. Only once the code is executed will we see a NoMethodError.

Okay, so we’ve discussed what an object-oriented and dynamic language means – is there anything else that sets Ruby aside that I should be aware of?

When it comes to memory allocation and deallocation, Ruby is one of those languages that handles it for you. Memory allocation and deallocation is baked into the language so that, for the most part, you don’t have to think about how to allocate and deallocate memory on a day-to-day basis–this is handled by Ruby garbage collection.

…garbage collection?

There are entire books written and countless talks given on Ruby’s garbage collection mechanism, but a concise explanation for just what Ruby garbage collection is, is that it’s a mechanism within Ruby that handles memory usage–both allocation and deallocation. Ruby provides an interface for its garbage collection so that, in the event that you need to adjust memory usage (or if you’re just curious like us!), then you can see just what’s going on under the hood.

And that’s it folks…

We hope that this post piqued your interest, as we’ll be diving deeper into some of these concepts in upcoming posts. Thank you for reading!

Mask and unmask a password input

Ridhwana Khan — Wed, 30 Jun 2021 10:09:49 +0000

I recently worked on a feature to be able to mask and unmask a password using some vanilla javascript, and I thought I'd share how I did this.

If you want to jump ahead and just see the code without the walkthrough, you can view the code on Codepen.

Step 1:

THE HTML:

Let's put some HTML together for a password field. In most instances that will form as part of a form but in this case I'm just going to go ahead and only show the div for the password.



<div>
  <label>Password</label>
  <div class="password-input-container">
    <span class="eye-container js-password-visibility-toggle">
      <span class="js-eye">
        <svg width="22" height="18" viewBox="0 0 22 18" fill="none" xmlns="http://www.w3.org/2000/svg">
          <path d="M11 0c5.392 0 9.878 3.88 10.819 9-.94 5.12-5.427 9-10.82 9C5.609 18 1.123 14.12.182 9 1.12 3.88 5.608 0 11 0zm0 16a9.005 9.005 0 0 0 8.777-7A9.005 9.005 0 0 0 2.223 9 9.005 9.005 0 0 0 11 16zm0-2.5a4.5 4.5 0 1 1 0-9 4.5 4.5 0 0 1 0 9zm0-2a2.5 2.5 0 1 0 0-5 2.5 2.5 0 0 0 0 5z" fill="#64707D"/>
        </svg>
      </span>
      <span class="js-eye-off hidden">
        <svg width="22" height="22" viewBox="0 0 22 22" fill="none" xmlns="http://www.w3.org/2000/svg">
          <path d="M16.882 18.297A10.95 10.95 0 0 1 11 20C5.608 20 1.122 16.12.18 11a10.982 10.982 0 0 1 3.34-6.066L.393 1.808 1.807.393l19.799 19.8-1.415 1.414-3.31-3.31zM4.935 6.35A8.965 8.965 0 0 0 2.223 11a9.006 9.006 0 0 0 13.2 5.838l-2.027-2.028A4.5 4.5 0 0 1 7.19 8.604L4.935 6.35zm6.979 6.978-3.242-3.242a2.5 2.5 0 0 0 3.24 3.241l.002.001zm7.893 2.264-1.431-1.43a8.936 8.936 0 0 0 1.4-3.162A9.006 9.006 0 0 0 8.553 4.338L6.974 2.76C8.22 2.27 9.58 2 11 2c5.392 0 9.878 3.88 10.819 9a10.95 10.95 0 0 1-2.012 4.592zm-9.084-9.084a4.5 4.5 0 0 1 4.769 4.77l-4.77-4.77z" fill="#64707D"/>
        </svg>
      </span>  
    </span>
    <input class="js-password" type="password"/>
  </div> 
</div>

The main element to take note of is the password-input-container. It contains two elements:

The eye-container with two spans that each contain an SVG (an eye and an eye-off SVG). The eye-off SVG will be hidden by default because the password is masked in its default state.
An input field with type password.

I tend to still follow BEM Notation for any classnames that I write. Hence, you will see that some classnames have a JavaScript namespace, and are therefore prepended with js- . This is a verbose indicator that this piece of the DOM has some behaviour acting upon it, and that JavaScript binds onto it to provide that behaviour. Hence, it reduces the risk of someone editing or removing the classname mistakenly without realizing that some javascript code depends on it.

Take note of the js- prepended classnames as this will allow us to bind the correct masking and unmasking behaviour in the JavaScript code.

Step 2:

THE JAVASCRIPT



let visible = false;
const eyeIcon = document.getElementsByClassName('js-eye')[0];
const eyeOffIcon = document.getElementsByClassName('js-eye-off')[0];
const passwordField = document.getElementsByClassName('js-password')[0];
const visibilityToggle = document.getElementsByClassName(
  'js-password-visibility-toggle',
)[0];
visibilityToggle.addEventListener('click', togglePasswordMask);

function togglePasswordMask() {
  visible = !visible;
  togglePasswordType(visible)
  toggleEyeIcons(visible);
}

function togglePasswordType(visible)  {
  const passwordType = visible ? 'text' : 'password';
  passwordField.type = passwordType;
}

function toggleEyeIcons(visible) {
  eyeOffIcon.classList.toggle("hidden", !visible );
  eyeIcon.classList.toggle("hidden", visible );
}

Let's walkthrough the code:



const visibilityToggle = document.getElementsByClassName(
  'js-password-visibility-toggle',
)[0];
visibilityToggle.addEventListener('click', togglePasswordMask);

We first search the DOM for the classname js-password-visibility-toggle. js-password-visibility-toggle is the container that contains the eye icons (one hidden and one not).

We then use add addEventListener to listen for a click on the element. When the user clicks on the element the function togglePasswordMask will be called.

The reason we do not add event listeners on the individual SVG span is because then we'll need to add two eventListeners to the DOM (one for the eye and another for the eye-off) and each of the callbacks will be doing something similar. Instead, we allow the trigger on the container and use a "sort of state" variable to figure out whether we're masking or unmasking.



let visible = false;
function togglePasswordMask() {
  visible = !visible;
  togglePasswordType(visible)
  toggleEyeIcons(visible);
}

The first time that we load the form the password is not visible, hence we set visible to false initially.

Each time we click on the eye icon, we toggle visible to negate its current value using visible = !visible.

When we click we want

a) the password to be revealed, i.e. togglePasswordType, and

b) the icon we clicked on to change - i.e. toggleEyeIcons.



const passwordField = document.getElementsByClassName('js-password')[0];

function togglePasswordType(visible)  {
  const passwordType = visible ? 'text' : 'password';
  passwordField.type = passwordType;
}

togglePasswordType simply sets the input type to text or password depending if we want to mask or unmask the password.



const eyeIcon = document.getElementsByClassName('js-eye')[0];
const eyeOffIcon = document.getElementsByClassName('js-eye-off')[0];

function toggleEyeIcons(visible) {
  eyeOffIcon.classList.toggle("hidden", !visible );
  eyeIcon.classList.toggle("hidden", visible );
}

toggleEyeIcons add and remove the hidden class name depending on whether the password is visible or not.

That wraps it up for the code, I hope that was useful and easy to follow. Feel free to drop comments or questions below. 👇🏽

My guide to solving problems

Ridhwana Khan — Tue, 21 Jul 2020 12:24:47 +0000

Recently, I gave a talk on Problem Solving where I shared some techniques that I use to solve problems at a high level as a software engineer. In this article, I’m hoping to summarise some of the aspects that I highlighted during my presentation, but feel free to watch the video below:

We use problem solving skills on a daily basis, but luckily for us, once we solve the problem a couple of times, it usually becomes second nature to implement that solution.

For example, imagine you move to a new home in a new town. When you start work again, one of the first problems that you will be presented with is to determine the route to travel to work. In order to solve this problem, you’ll probably use a tool, like Google Maps, and then perhaps you may do some research by asking the people that you know how safe the route outlined is. You may also want to amend the route in order to pass a coffee shop, and finally you’ll try it the first day and then tweak it. After you’ve found a solution to this problem, it becomes second nature to get to work, and you no longer need to give it any thought, thus freeing your mental capacity for other problems.

In the same manner that we’ve solved this problem, we can apply similar techniques to solve software engineering problems.

Let’s get into the headspace..

I’ve often found myself going around in circles because I’ve started typing out a solution without taking the time to go through a process. If I have a daunting task, I am in one of two modes; either I have just not mustered up the courage to start the task or I jump into a solution without taking the time to understand the context and problem. Hence, I started using the following process to help me problem solve. It mostly increases the initial time, but the long term payoffs have been really beneficial.

The first step in the process is to set some focussed time. During this time I make sure I understand what I want to achieve.

Now, let’s identify the problem?

Thereafter, I begin to learn more about my problem in order to understand it. I’ve been in so many meetings over my career where someone is talking to a boardroom of people about a solution, but it turns out that nobody actually understood the initial problem in the first place. Therefore, they’re not really contributing towards a practical solution.
In order to ensure that I have clarity on the problem I like to use the following techniques:

I ask questions. When you’re new to a team, company or industry this can be a bit daunting, but over the years I’ve come to realise that most of the time others have similar questions to the ones I have, and they’ve led to fruitful discussions.
Once I think that I’ve understood the problem, I like to reiterate my understanding of the problem to someone more knowledgeable. I usually say something to the effect of “Ah I see what you mean, do you mind if I explain it back to you to ensure I have clarity on the problem”. The result is that it shows the other person that you have been listening attentively and trying to understand the problem. It will definitely make you feel vulnerable as it will expose the gaps in your knowledge, but once you’ve had this conversation your knowledge then becomes stronger and more solidified than ever.
Visualising a problem can also be key. Rather than merely using words to describe, analyze and solve the problem, using images is useful. I once read somewhere that "Images help the brain clarify ideas, identify underlying patterns of logic, and create meaning. A good visual invites the eyes to dart around and engage the entire brain to create a visual logic and make sense of the information to which it is being exposed. The more fully the brain is engaged in the act of analyzing and creating meaning, the richer the outcome of the problem solving activities will be. " “Taking problems to the drawing board or whiteboard” is a common term for that reason :)
Finally, I spend some time gathering information. This can often be done through talking to people who have solved something similar. They are also called ‘domain experts’. In the context of my example at the start of the article, this would be the equivalent of asking people in the neighborhood about the safety of routes. Gathering information often arms me with knowledge to see the situation more clearly, and look at the problem in a new or different way, as well as identify options that may have not occurred to me previously. I also gather information by browsing around the net for articles and insights on how people have solved similar problems before.

The more clarity that I have understood the problem, the easier the process becomes. Implementing a solution halfway to realise that you didn't actually fully understand the problem, or that you’re solving for the wrong problem can often lead to economic loss or delays in release.

Often, when I finally have a full understanding of the magnanimity of the problem, I tend to go blind panic mode, whereby I feel like the problem can't entirely fit in my head. I feel overwhelmed. This is when I take a deep breath and remember that everything can be broken down into bite-sized pieces.

Shall we break it down further?

Big problems are nothing more than a collection of little problems. The faster I can break those big problems down into solvable component problems, the faster I can generate ideas that will resolve my issues. I take my big problem and I ask, “what is this big problem composed of ?”, “what are the smaller issues that seem to be driving the big problem”. I break them down and then continue breaking them down into smaller and smaller issues until I can find a solution to the smallest component. Breaking up the complex problems into smaller ones that are in their simplest form allows one to rationalise about them more easily.

Let’s move from problem identification to problem solving.

Now that we’ve broken down the problem, we can start planning a solution. When planning a solution,, I use visual tools, like process flow diagrams which provide good ways to determine the flow of a solution and the different paths; or in the case of application flows, a UI sketch plays a part in forming a holistic solution thereby eliminating missing steps.

Once I have all the building blocks in place, I’m ready to move to the implementation stage. When working on big software problems, writing pseudocode is a must for me. I think of pseudocode as a sketch, or a blueprint, that allows me to first focus on the essentials before diving into the specifics.

One important benefit of writing pseudocode before programming is to catch potential mistakes from the get-go. It’s far cheaper to fix mistakes before the development process begins. I tend to write my pseudo code as comments in the appropriate files.

Thereafter, we just use our programming language to implement our solution to the problem. We translate the pseudo code into actual code.

Finally,

Once the solution is packaged up in code, I am usually caught up in a whirlwind of activities on whatever the next priority is. However, I’ve been trying to get better at reflecting on the problem and the way that I’ve solved it. The few times that I have done this, I’ve found that I was always able to tweak or optimise my solution in some way.

Reflections for me have sometimes taken the form of a blog post, a talk or even a chat with a colleague. It's to help me to put my thoughts in perspective, to help future me when I stumble across a similar problem and also just to share my learnings. And hey, I always feel proud of myself when I reflect upon the process, it builds up my confidence for the next problem I’m about to solve.

All in all the reflection process is the best part of the process to get to because it feels like the calm after the storm and it's time to bathe in the glory of your hard work.

Until next time…

Let’s keep solving problems 😊

Today I learned (or maybe googled)...

Ridhwana Khan — Thu, 23 Apr 2020 11:54:48 +0000

I've decided to start a "Today I learned/googled..." series where I'll be writing about what I've learnt or even googled.

Why start it?

Every day whilst I'm working, I google tons of things, some of which I forget and end up googling again, and some which I actually end up retaining.

I search the internet for all kinds of stuff - things that are related to syntax, the quirks of a language, the magic that happens behind a framework, or sometimes even solutions on how to solve a problem within the bounds of a language.

A prime and somewhat random example is every time I write a post or any markdown I have to search the syntax for a link, or do a trial and error on whether it's like this (Name)[LinkUrl] or link this ✅[Name](LinkUrl)

My computer science degree and my senior engineer title knows no bounds and they're constantly learning from the master, google. 🤫

I’m also always learning from peers, and from reading their code. Recently though, I've been working on the open source project at DEV, as part of the core team, I now actually spend a huge portion of my time not only reviewing my peers PR's but also external contributors from all over the world with such varying experience and skills. These PR's are major sources of my learning on a daily basis.

It makes me want to investigate deeper into things I am interested in, to share my knowledge, interact with others about the things that I’ve learned about, to exhibit how after 9 years of being a developer I still google the silliest of things 🙈, and finally it makes me just want to write some more, which I've been wanting to do for ages.

I've enjoyed reading Hashrocket's TIL for some time now and so I thought why not share something similar on a platform I love using.

So, what should you expect?

Let's start with nothing much at first, I'd love to just showcase anything random that I learn, or anything that I know but I've had to google again over and over. Some posts may be obvious, some may be silly, some may be useful, but it's supposed to be fun, so let’s see where this goes... I'd love to have discussions and for you to pop tips and tricks that you learnt in the comments too. You'll probably see some javascript, ruby, and general coding stuff.

I'm bound to learn new things every week, so why not share it? 😊

Exploring the path of a new and unfamiliar codebase

Ridhwana Khan — Tue, 07 Apr 2020 07:51:55 +0000

About 2 months ago I changed jobs, I started working at DEV. As a senior developer, I’ve been through the process of finding my way through a new codebase a couple of times, and each time it seems to get a little easier and quicker. However, irrespective of skill level, there will always be an adjustment period, where I enjoy spending my time feeling around the codebase that I’ll be working with. Then, over time the code seems less daunting, I start making traction, I get more confident and then finally one day I feel like I’ve been working with this codebase all my life. 🛣

Doing it a couple of times has made me realise that there’s been some method to my madness; there are some general guidelines and techniques that I follow to familiarise myself with a new codebase. So this time, as I started working on the DEV codebase, I documented this method to my madness 📝

So, where do we start?

Let’s explore the production application

Before I join a new team, I usually do some basic research on their product. I tend to download and sign up for their application as part of my interview preparation. In some cases, like DEV, I’ve already been using their platform for a while and I’m familiar with it.

However, before tackling a new codebase I still take some time to explore the parts of the interface that I don’t regularly use. For example, with DEV, I familiarised myself with the different types of editors, I explored the filters, I looked through settings, I navigated to the sponsor pages. I want to know as much as possible, and I let myself just go on a journey of exploration.

I also prefer getting a demo of the product from a team member if possible. During these demos I usually find myself being alerted to parts of the system that I did not or would not stumble upon myself. Sometimes, it's the admin interface that I did not have access to as a user or perhaps a page that was tucked away and only gets used by a certain type of user.

An exploration of production also helps me to realise what the local setup of my environment should look and behave like. 🔎

Now, we can clone the code and setup your environment

Next up, I clone the application (if I haven’t already).Thereafter, I briefly read through the documentation for setup instructions.

I feel no shame in saying that when I get stuck on any errors (setup or otherwise), google and stack overflow are my best friends 😁. If that doesn’t work, I ask questions on my team chat, everyone on the team before me has set up the project so that means someone has most likely encountered the issue before. Also, as I grew as a developer I learnt the balance between having to figure out the important things by myself vs asking for help. A team is there to support and help each other, and it is beneficial to ask questions. Once I’ve figured out how to proceed, I always make sure to add my findings or anything that took me some time to figure out back to the documentation so that it helps the next person.

Once I’m all set up, I explore even further, this time within the codebase. I read through some code, navigate the file structures, take note of the packages and code styles that are used, and even just read some tests.

Choose some bugs or simple tasks

Exploring is not enough, doing is key. When we do, we end up solidifying our knowledge and we put the theories we have about the code into practice.

Now, unless I’m working on a green fields project, every project has bugs - literally every single one 🐞. I like to pick up some of the bugs in the project. I do this because I believe that fixing a part of a codebase allows me to get a much more detailed view into the system. It also keeps me focussed on my end goal of getting this small piece of functionality working without the pressure of having to think about the aspects like UI and UX of a new feature. I don’t end up getting stuck in the details, because the details have already been implemented. In addition, there is very little uncertainty about the functionality because it was determined a long time ago. Removing all these other factors allows me to focus on what I need to - just the code. It also allows me to make progress and get more confident in the codebase.

Keeping the above in mind, when choosing my first bugs, I try to stay away from complex, uncertain and not easily replicable ones that will cause me to feel overwhelmed and block on my traction. In the open source world, like DEV, this is equivalent to the ‘good first issue’ tag. Once I’m past the exploration phase that’s when I like to challenge myself even further and take on the ones that hurt my brain 🤯

Debugging and Solving the bug

Finally, when I tackle the bug head on, there are a couple of techniques that I use. These techniques are not unique to a new codebase, but they can be applied to any problem. Here are some:

First, I break up the problem into more manageable components, until they are small, less complex pieces. I then work through each piece as a task.

When debugging, I trace through the code in question from start to end (i.e. across the backend to the frontend) in order to find the point where the issue lies. I do the following:

I use loads of logs! There's been times when I've added logs to every single function in a file to figure out it's path. Once I know the path then I’m easily able to figure out what may be going wrong. During this time, I’m learning about how the code works. The two things that I do diligently is I name my logs appropriately so as to not get lost in them and I also keep a note of the order of the logs (especially in javascript where things get performed asynchronously).
When I’m stuck, I sometimes comment out pieces of code, just to see what the repercussions are and how or if the system explodes 💥. Commenting out code usually indicates to me whether I’m looking in the right place. If I comment out code and the interface or feature still continues working, it means I’m clearly working in the wrong area of the codebase. I always keep in mind that I should not be afraid to try anything, it’s usually not possible to break an application in the development environment (at least I really hope so, or else we have bigger problems!!), and everything should be reversible. P.S, make sure that when you changing code on your development environment, you’re not mistakenly refreshing production wondering why your change is not working 🤦🏽‍♀️ Yes, this has happened to me numerous times!
I use debuggers to stop the execution of the code in order to play with portions of the code that don’t make sense to me.

That sounds cool, but, what if I’m still stuck?

If after debugging I find that I’m still stuck, I do some more research, try writing down the problem and maybe even rubber ducking, but at some point if all that doesn’t work then asking for a second pair of eyes 👀on the problem becomes key.

When we’re asking for help, it's important that we give colleagues as much information about the problem. I usually start off by describing the problem to them, then explaining what I tried to do to solve it and what were the findings of it, and finally I ask direct questions on the portion of the code that isn’t making sense or that I need assistance with.

Showing the work in progress also helps to give the other person perspective, as well as helps them to visually see what you’ve been working on to be able to assist. It reduces the time wasted for them to have to try that which you’ve tried already. It is for this reason that draft PR’s have become really useful. Besides, it's better to get feedback earlier rather than later. Finally, if asynchronous feedback is not helping, don’t feel shy to ask someone in the team who's more knowledgeable on the topic to pair program just to get over the bump.

During this process, what should I be mindful of?

I believe that changes should be made incrementally instead of in one ginormous pull request. Testing often is essential too.
Being conscious of the changes we make and adhering to the coding style ensures that we have a consistent codebase. It's important to feel confident to make improvements in the application, but when introducing new tools or technology that will affect other teams or the direction of the project we need to be sure to consult or give a heads up to everyone else (depending on the flexibility of the company).
Irrespective of our skill level, we need to remember to be empathetic and kind to the person who wrote the code before us. Often I hear developers refer to the crap code that they inherited from the previous developer, but we need to keep in mind that we do not know the full context of the situation under which the code was written.
Sometimes we’ll end up breaking things - shit happens, acknowledge it, learn from it and move on!

In conclusion, when one is not armed with techniques to approach a codebase, it can feel overwhelming and intimidating. However, as soon as there is a method to the madness it can easily metamorph those feelings to excitement and enjoyment instead. I hope that this does that for you :)!

Nevertheless, Ridhwana Coded

Ridhwana Khan — Mon, 09 Mar 2020 08:15:38 +0000

As I was growing up, when I was asked what I wanted to become, it started off as a 👸🏽princess, then a 🚗car racer, a 👩🏽‍🏫teacher, an 🧾accountant, but never did I once say any type of engineer.

You see the thing is, I’d never really seen any girls operate computers or build bridges. I knew what the world taught me - pink is for girls, we play with princesses, and maybe half day jobs with holidays are best.

I didn’t learn to program from an early age and I didn’t know anyone that did, in fact to be honest I didn’t know what programming entailed.

Almost a decade later... and I'm a software engineer at DEV, a company whose mission I believe in, I speak at conferences about the things that I love, and I run a non profit organisation to help others. I'm not a princess, but I am someone that has mapped out her own journey and worked really hard to get there, so maybe I could be my own superhero?

Nevertheless, how did I get from wanting to be a princess to becoming a software engineer?

Firstly, I have parents who didn't limit me. They let me choose the career path that I wanted to even though I really had no clue what Computer Science was, but they let me explore and knew I would find my path.
I worked really really hard. It wasn't always easy. Coming from a non-coding background, I felt like I lagged behind with understanding certain coding concepts at university, because it was assumed that I had done coding at school. Whilst I was learning what an if statement was, the curriculum dictated that we built web sockets already.
Once I was in the industry I didn't let being the only women in the room stop me. Yes, it was difficult, and I had to prove myself over and over, but I did it until I no longer needed to.
I learned and forced myself out of my comfort zone - the bigger the challenge, the more I wanted to achieve it.
And finally, I let myself be inspired by others in the industry. I took on mentors when I felt that I needed guidance, and I asked for help when I was lost. I contributed where I could.

There are still challenges that I'm overcoming on a daily basis but I finally believe that we can overcome them together as an industry. Each day in the smallest of actions, I strive for a world where:

everyone gets paid equally, based on their skills and NOT their gender.
a women in the boardroom no longer has to prove herself, in order to get her voice heard.
tech conferences are filled with diversity and the excuse is no longer, 'but we couldn't find a women'.
the working environment is tailored to suit the needs of both men and women.

I believe that over the last decade we have made progress, but we still have a long way to go. It is with constant awareness and small changes that lead to bigger ones that we can get there.. together. On that note, Happy International Women's Day!💜

Performance Budgets, do you use them?

Ridhwana Khan — Tue, 03 Mar 2020 10:20:11 +0000

I've been doing loads of more research on Performance for the past couple of weeks and Performance Budgets have caught my eye. Curious to know how many teams use performance budgets and how you've implemented them? Also, what kind of improved ripple effects has this caused?