DEV Community: Sdu

null vs undefined? What to choose? What to use?

Sdu — Wed, 23 Aug 2023 09:32:50 +0000

If you have experience with writing JavaScript, you might have a preference of using undefined in place of null, and even go to an extent of casting null values to undefined instead. If you were any wiser, you'd have known that null and undefined are not supposed to be interchangeable.

Of course, the caveat of choosing one over the other, and/or switching between them isn't much of a conversation starter as it rarely causes any head turning issues in production...rarely! I say this because I'm certain that the use of a wrong type has caused issues which were solved without being fully understood.

Okay let's look at specifics.

null

null is a primitive value that represents the intentional absence of any object value. Probably the most common keyword across a lot of programming languages and with a common definition too. Other languages get fancy and use nil instead. I'm not quiet sure yet if that's also an exact equivalent to null, but it's worth checking out.

undefined

undefined is a primitive value used when a variable has not been assigned a value. This is just a JavaScript thing. With JavaScript you can travel back in time to make a variable not assigned a value.

"But black dynamite, assigning null to a variable does the same thing" see that's where you'd be wrong. Here's an analogy for you. We can say null is like loading a webpage and just getting a blank screen, but undefined is a '404 not found' error.

The two keywords do have some common traits though. Ones that I can think from the top of my head is, they're both falsy values. This means that if you have a Boolean expression like if (null || undefined) you'll always get false from it.

What to choose? What to use?

Let me get this out the way first. You shouldn't really have to choose. Your circumstances have to either choose for you or you make the choice depending on the solution for the problem you're solving. This is the answer to almost every 'vs' question in programming, but no one likes it as it ends arguments too early.

Speaking of circumstances choosing for you. In most cases, if not all, variables that hold data moving to/from the user to some data store, even via http requests, you must have at some point dealt with transforming it or the form of it to JSON. JSON is an open standard file format and data interchange format.

When consuming APIs through some library or dealing with databases, notice how your favorite library hints to giving you either the data of some property or null? Why don't your orm or database connector thingie mabob give you back a property as undefined? Because at that point it would be extremely difficult to tell whether the property in the structure you're dealing with even exists. Getting {"foo": null} is better than {} because I know that 'foo' does exist in some other condition. When you get a chance, open a javascript console and run the following:

JSON.stringify({
  foo: null
  bar: undefined
})

Typescript particularly makes these choices very loud, as when you're defining your types, you need to specify whether a property of an object or a variable can hold either null, undefined or some type.

Let's make a scenario to conclude this mini rant.

You're writing a form with your favorite framework, that when a user types, a request to update the data is made to the backend and your backend should only update the fields that have been changed. Let's also assume we're using RESTful apis to further pin down the scope. How does your frontend communicate this? Lets say the form is for user details and the fields are "name", "age", "height".

If the request payload from the client is

{
  "age": 24,
  "height": null
}

The backend can interpret this payload as:

Property 'age' exists and has number. Update age with provided integer
Property 'name' is not defined. Do nothing
Property 'height' is null. Clear its field in the data store.

How does the backend figure out that the property 'name' is not defined? Because it isn't.
That payload is equivalent to the following

const body = {
  age: 24,
  height: null,
  name: undefined
}

Where the inclusion of 'name' is redundant. Misuse of 'undefined' in such cases is a common place for bugs too. When this object is used to create URL search parameters, it will interpret the keyword 'undefined' as a string, which hopefully if your favorite http client omits undefined properties for you in requests, you're lucky, but some serialize it incorrectly.

I even resort to having a helper function to create query parameters from an object to avoid this

function createUrlSearchParamsFor(payload) {
  const safePayload = payload ? JSON.parse(JSON.stringify(payload)) : payload
  return new URLSearchParams(safePayload);
}

When a javascript object is being serialized, all undefined properties are discarded, remember 'undefined' means a property is yet to be assigned a value. But null on the other hand is known by JSON as its a valid JSON data type

That's it. Hope you learned something.

If you spot any interesting bits or tweaks to be done on this post, let's discuss it here or reach out on twitter

Firebase authentication you can eject, used with any backend

Sdu — Wed, 17 Feb 2021 08:07:45 +0000

Firebase is great for prototyping projects, especially when you really want to focus on your frontend or mobile app. Plus getting a server up and running from scratch is tedious. So with a couple of clicks, you have a database, a way to authenticate your app and storage, all for free.

But that, still, comes at a cost. The trade-off of how easy and readily available firebase features are is that it locks you in to their ecosystem. I mean, it doesn't matter the type of project, its really uncomfortable adding features to a project that you know at the back of you mind, will be a pain to move to another infrastructure. Like for instance, firebase SDKs make is sooo easy to store stuff into their database solution, you don't need to worry about schema and what not, but rather how the data maps with objects in your app. But it being so easy, means that how you think about you data structure should adhere to their document object model. And for some solutions, data relativity gets very complex where using a relational database would have been ideal.

Take for instance, you come up with a revolutionary to-do application that probably can add tasks before you even think you need to do them. Great idea isn't it. You don't want to spend too much time reinventing the wheel with chores like logging in, registration and a solution like firebase comes in very handy here. That being said, you want to write your server code in python, to leverage some AI library you just read about online, and you really really want to use MySQL. Conflicting I know! You can pretty much plug and play with a buttload of services available out there but choosing which corners to cut and where to put in the effort is a bit tough. And its your responsibility as the millionaire to be. I will however help you cut one corner with this post.

Lets stick to the theme, authentication. We'll use firebase for our client. Either web or native app, it doesn't matter. But for our backend? Anything. I was using(learning) Nestjs at the time I stumbled onto this solution so bare with my code samples. So you client will use any firebase sdk for authentication and your server should be expecting and verifying a Json Web Token (JWT).

Why firebase?

"Why not I just write all the authentication logic by myself?" Fair question to ask. Especially given the amount of online resources available online for implementing this. But authentication is not just logging in, or registering a new account or the funky access token validation.

There's account or email verification,
There's account reset or password retrieval,
There's single sign on solutions i.e. logging in via Google or Twitter and,
There's making sure that multiple sign on options still work together,
There's access token management. The big ol question of storing the token in memory, local storage or as a cookie.

All this could take up half or more of the time you could have spent perfecting your project idea. Firebase already solves all of this, so we'll use that instead.

Yea nah. You don't need firebase on your server.

Again, sticking to the theme. We're building our own backend, or have build our own backend and we only want to tie up authentication. Here's the beauty, there's a section in the firebase docs that goes:

If your backend is in a language not supported by the Firebase Admin SDK, you can still verify ID tokens. First, find a third-party JWT library for your language. Then, verify the header, payload, and signature of the ID token.

We strike gold here. Conventionally, you would have to install the firebase admin sdk to manage how your users are authorized in the backend. For simpler nodejs projects, this is no issue, but I started to struggle trying to use that admin sdk when working with a very opinionated framework, Nestjs. And getting to these docs you realise:...

How it all works

Lets start with the client app. Honestly I don't think it's necessary for me to elaborate on how to setup firebase authentication for your app. There's plenty of tutorials online for that, and their docs are pretty comprehensive. But given enough reasons, I might edit this to include some example or something. When your user signs in, or signs up i.e.

    // This is what some method looks like inside my nuxtjs application to log me in :)
    await this.$fire.auth.signInWithEmailAndPassword(
      this.email,
      this.password
    );

Upon success, you'll be able to retrieve the token from wherever within your app to make server requests with, along with other properties your app has been granted access to by the user i.e. email, name etc. by listening to firebase events like so:

    firebase.auth().onAuthStateChanged(function(user) {
      if (user) {
        // User is signed in. Get what you need here
        // you can call user.getIdToken() from here and store it anywhere you want
      }
    });

Now requests from there will look something like below. It really doesn't matter how you get your token to the database, whether as authorization header or you pass it as a query parameter with your API url as long as it follows the OAuth standard or it is what your server is expecting. A simple authorized request should look something like this

    fetch("https://some-api.herokuapp.com/users/me", {
      "headers": {
        "authorization": "Bearer <your token here>"
      },
      "referrer": "http://some-app.herokuapp.com/",
      "referrerPolicy": "strict-origin-when-cross-origin",
      "body": null,
      "method": "GET",
      "mode": "cors",
      "credentials": "include"
    });

In this case, firebase stores a cookie in the users browser to persist the session. I advise that you don't persist the access token but rather keep it in memory, and get a fresh one if you loose it. This is because the access token is very short lived as it should, you expose some security vulnerabilities by doing so, and one of the reasons for using firebase in the first place is to have that all handled for us.

That string token you get from firebase is an actual valid JWT, so "thank you firebase but we'll take it from here". Here's how things will essentially work

When a request is sent to your server, you need to follow a couple of steps to validate the firebase token.

Ensure that the signing algorithm is "RS256" and that the signature is valid.
Validate the token payload claims

1. Ensuring that the the signature is valid

There are many ways to achieve this, depending on the choice of your server stack. Here's how you'd typically do it if you were using an npm package like jsonwebtoken :

    jwt.verify(token, publicKey, options, function(err, decoded) {
      console.log(decoded.foo) // bar
    });

where the verify function takes in 1) the token to verify, 2) the public signing key and your options as an object. Follow the link to learn more about this. More on public keys in a moment. You should be able to pass in the required signing algorithm within you options.

For ASP.NET Core users alike, the System.IdentityModel.Tokens.Jwt package should be sufficient enough to achieve similar results if not the very same. I'd love to provide an example here but I don't think I have a fitting one as I'm still a bit fuzzy on the platform. I do however have a .NET Core public repo with a working jwt example which can be modified to fit this use case for the hopeless looking for a starting point.

Now, the tricky part, and the most important. Getting the public key used to verify the token's signature. Firebase public keys are actually available and accessible from the link https://www.googleapis.com/robot/v1/metadata/x509/securetoken@system.gserviceaccount.com as a json object. This json object usually carries two keys as I've seemed to notice, and to get the one that will work for you, you need to use a key ID or (kid) found in you token's header when decoded. Now you'll use the key ID (kid) you get from your decoded token's header to get the public key as you would with any other json object, like so:

    const response = await getPublicKeysFromGoogle();
    const publicKeys = response;
    const [header64] = rawJwtToken.split('.'); // refer to the structure of a jwt
    const header = JSON.parse(
      Buffer.from(header64, 'base64').toString('ascii'),
    );
    const thePublicKeyIWant = publicKeys[header.kid];

As a refresher, a jwt is made up of 3 parts when encoded, seperated by dots ( . ). The header, payload and the verify signature part. The snippet above merely splits the token and only grabs the encoded header, decodes it to then grab the kid (the key id). From there, it extracts the public key from the object returned by my helper function getPublicKeysFromGoogle() which looks like:

    async getPublicKeysFromGoogle(): Promise<AxiosResponse<string>> {
      const response = await httpService // httpService comes from nextjs, you can use fetch or axios for this
        .get(
          'https://www.googleapis.com/robot/v1/metadata/x509/securetoken@system.gserviceaccount.com',
        )
        .toPromise();
      return response.data;
    }

There are two problems with my helper function for now. These public keys expire so we can't fetch them once and save them somewhere but you can refresh them by using the value from the max-age in the Cache-Control header of the response from this endpoint. Secondly, we don't want to send a request every time any of our endpoints are hit, it would slow us down for probably 200ms-350ms depending on where you're hosting your server and that is baaaaaad because this is just for verifying a token, excluding the time you will incur as you satisfy the request. To solve this, employ a cache mechanism and modify the little snippet above.

    async getPublicKeysFromGoogle(): Promise<AxiosResponse<string>> {
      const keys = await cacheManager.get<string>(
        jwtConstants.publicTokenCacheKey,
      );
      if (keys) {
        return keys;
      }
      const response = await this.httpService
        .get(
          'https://www.googleapis.com/robot/v1/metadata/x509/securetoken@system.gserviceaccount.com',
        )
        .toPromise();
      const { 'cache-control': cacheControl } = response.headers;
      const [, maxAgeString] = cacheControl.split(',');
      const [, age] = maxAgeString.split('=');
      const ageInt = Number.parseInt(age);
      this.cacheManager.set(jwtConstants.publicTokenCacheKey, response.data, {
        ttl: ageInt,
      });
      return response.data;
    }

Here's what's different here; I first check the cache for the keys and return those if I find them, if not, continue fetching them from the endpoint. Now from the response headers, I extract the time remaining, in seconds until these keys expire, and set the keys in cache with the same expiry date I got from my headers. This ensures that I only have to re-fetch the keys once they have expired. Now with this, we have verified our signature.

2. Validate the token payload claims

So apart from the signature verification which ensures that the jwt used with the request is issues by Google for real, we need to also validate claims that are in the payload. This ensures that the request isn't being sent with a possibly hijacked token or something. There's a comprehensive list of claims to check listed here at the bottom of the page, under "ID Token Payload Claims" to which I won't bore you with relisting them again.

To sum up

By the time your app has grown to have so many users that you now need to leave firebase and you can focus on reimplementing authentication on your own, you will only need to change a very small part of your servers logic. How token verification is done, as you won't be using Google's public keys anymore, and I guess which claims to validate. and that's rarely any more of a chore compared to the refactor you will need for your front end. But that's one less part of your system you don't need to worry about anymore.

I wrote this because I once spent hours trying to figure it out and with one or two php solutions online which are older than my own knowledge of php lol. I hope this helps at least one person, and if it's more, that'll be great. I generalised most things here hoping to have this piece less technical as possible but it ended up not turning out that way. If there are any additions, suggestions or any clarifications that you need added here please drop me an email at bs.gumede@outlook.com or inbox me on twitter @sduduzo_g . Neutral to positive criticism is very welcome, and will most likely drive edits to better improve the article and my writting too.

I used carbon.now.sh for the cover image

and I used umletino for the diagram.

Introducing purgitory. My first npm package :)

Sdu — Sat, 12 Sep 2020 18:38:40 +0000

Introducing purgitory. My first npm package :)

So purgitory is an npm tool to An npm tool to purge local branches that have been merged and deleted to the main branch in remote.

Working in a fast paced project and/or projects basically means I'll be creating, checking out and reviewing around a dozen of git branches per week, and from this, I found myself with a bunch of stale branches locally to which most have been merged into master as the work has been deployed.

I needed something to clean my local repositories, many people do. So while I was pair programming with my teammate this past week he asked me "Hey man, what do you use to remove merged branches locally?" and my answer was "there's a way, google search 'git purge local merged branches' and you'll definitely find some bash script on stackoverflow" not a good answer, I know. But then that's what I always do. I surf the internet until I forget what I was looking for in the first place. Now because there's no easy way to do this, the number of branches locally kept on growing. Clearly we need a solution for this.... and it hit me

"Fine, I'll do it myself" - This phrase, every time I fail to find a tool for something, it hits me, and then another side project is born

So immediately after work on Friday. I took a nap, or at least tried to, but I couldn't because I was trying to figure out "how do I make this super simple?", "how do I make it easy for myself to accomplish this?" and "what would I consider a complete project" and while asking myself those questions I jotted a couple of notes down and went to work.

This how how purgitory was born.

The name is like a combination of "purge" and "git". I asked my colleague "what do you think of this name?" and he was like "I just want to use the thing, the name sounds cool" and well.... so if the name doesn't make sense, that's because the focus was on getting this thing to work.

I had a choice to write this in either c# or javascript, but because of the npm ecosystem, it was easier to lean more towards javascript just so that the tool is easily accessible to a wider audience easier and there are packages for interactive command line tools I can use from npm to make this easier for me.

This was written 24hrs after the first version "0.0.1" literally had a 'console.log("foo")' which didn't work obviously as I learned. But that was the whole point. I heard a quote today from Stefan Mischook "You wanna learn how to fight, you fight" which I resonated with greatly as it's been how I've probably learned everything I know today, or most of it. By diving head first into a challenge.

Hacktoberfest is coming!

Sdu — Thu, 20 Aug 2020 14:41:18 +0000

Hacktoberfest is coming!

cover image source

TL;DR;

Do open source stuff on the internet, get free stuff.

So What's Hacktoberfest?

It's not a month long beer festival, I first thought it was, but no 😒. It is a month long festival of code organized by DigitalOcean where you participate by simply opening a pull request and contributing to any open source project. All backgrounds and skill levels are encouraged to complete the challenge. In every year, you're given instructions in how to complete the challenge, last year, it was to submit at least four pull requests to any public repository on Github and you're done. Last year, the first 50 000 contributors received limited edition T-shirts and a bunch of cool stickers. This year though, the first 75 000 participants can earn a T-shirt.

Now to be fully immersed in the experience I really recommend you to follow the #hacktoberfest tag on dev.to and don't be shy to share you journey with the world there.

"I've never contributed to open source before, I don't even know where to start"

Have I got news for you. That alone makes you the perfect participant all on its own. Many people believe that contributing to open source means writing super complex code and/or fixing issues the author of the project could have never figured out. Which, in so many lengths, is not true.

To put this simply, with a quick example. One of the pull requests I submitted for the 2019 hacktoberfest challenge was editing a README for just explaining steps to setup firebase on an android app. Just that one page, and I had contributed to open source, 3 more similar pull requests sent out and I had completed the challenge thus receiving my 2019 hacktoberfest swag.

A few tips on how to find projects to contribute to

Search for the keyword hacktoberfest on Github

A trick to get contributors on board by project maintainers is that they label some github issues with 'hacktoberfest', especially during these times of the festival which makes it very easy to filter down to repositories who are looking for help or looking to help you contribute. Other labels to look out for are 'good first issue' and 'beginner' which imply that you do not need to be an expert or super skilled and even versed on a certain project to take a jab in solving that issue.

Ask around your circles if anyone needs an extra hand in their public projects

Sometimes it's the people who are close to you who could also use a helping hand with their projects. You might be also working in a company or a team that maintains some open source repositories, that's your chance to also deal with some minor typos in their documentation here and there, adding some tests or just organizing their file structure for easier consumption.

Be on a lookout for online tools used to search for projects on github

Tools like http://issuehub.io/ https://gauger.io/contrib and https://www.codetriage.com/ make it so easy to scan through the many projects out there to tackle. I personally like http://issuehub.io/ because it's pretty intuitive and I think it's the one I've been using even way after the festival had passed

For more detailed information (because I'm writing this out of excitement) please see https://hacktoberfest.digitalocean.com for more details.

Creating an auto resizing textarea with Vue Composition API in 4 easy steps. I can't wait for Vue v3

Sdu — Fri, 07 Feb 2020 23:30:57 +0000

I'm assuming you now know how to add @vue/composition-api to your project so I won't waste any more time.

Step 1

Where ever you need to, in your template, just add the textarea element like so:

<template>
    <!-- anything else you probably had -->
    <textarea ref="myTextArea" v-model="content"></textarea>
</template>

Notice we added a ref attribute. name it whatever you like. Don't forget the v-model.

Step 2

Create the composition function. I created mine inside the same component file I created the textarea in. You can even create a separate file for it if you like.

function useTextArea() {
  const myTextArea = ref<HTMLTextAreaElement>([]); // remove <...> if JS
  const content = ref("");

  return { myTextArea, content };
}

If not done automatically by your editor, add the following import statement

import { createComponent, ref, watch } from "@vue/composition-api";
// remember 'createComponent' is not needed/used in javascript

Step 3

Expose these properties to your Vue template. We do that in the setup function's return statement

export default createComponent({
  // ... other things you did.
  setup(props, context) {
    // ... some other stuff
    const { myTextArea, content } = useTextArea();
    // ... maybe some more stuff, I don't know
    return {
      // ... maybe other things are here too, your things
      myTextArea,
      content
    };
  }
}) as VueConstructor;

I usually add as VueContructor just to stop the noise from eslint and vue-router complaining about the component's expected type. Not really a requirement.

Ok everything is neat now, there should be no errors but nothing works yet. We do however have a reference without having to use this.$refs bacause obviously we don't have access to this in our setup function. But through the magic of the composition api, the concept of refs is unified.

Step 4

Making it work. We go back to the useTextArea function to add a couple of lines to watch for changes in the textarea's content and calculate the element's new height after that.

function useTextArea(){
  // ... after variable declarations
  watch(() => {
    if (content.value.length === 0) return;
    myTextArea.value.rows = 2; // depends on what you want initially
    const styles = window.getComputedStyle(myTextArea.value);
    const paddingTop = parseInt(styles.paddingTop);
    const paddingBottom = parseInt(styles.paddingBottom);
    const padding = paddingTop + paddingBottom;
    const currentHeight = parseInt(styles.height) - padding;
    const initialHeight =
      (parseInt(styles.height) - padding) / myTextArea.value.rows;
    const scrollHeight = myTextArea.value.scrollHeight - padding;
    const newRows = Math.ceil(scrollHeight / initialHeight);
    textArea.value.rows = newRows;
  });
  // ... before the return statement
}

Aaand done. You now have a textarea that adds or removes rows if there are any changes with it's value. You don't have to know off hand, the height of your element or the font size of the content, which can change anytime.

One concern I have is just the performance of the code inside the watch function. If you have a better implementation please link it in the comments, I'd love to see different ideas around this. I've never enjoyed writing VueJS like this ever before.

C# and .NET Core Appreciation Post. The most beautiful piece of code I have ever seen... this month!

Sdu — Mon, 09 Dec 2019 13:24:19 +0000

Disclaimer!

This post is a little bit ridiculous and over the top but I'd be doing injustice if I do not share my thoughts on how the journey of learning something new feels like. But if you're in a rush, just scroll to the snippet at the bottom

So here's the thing. Years ago, when I had just started programming, as part of my degree, I hated C#. I didn't want anything to do with any project related to Microsoft related tech. Here's the rationale behind this (it's a dumb rationale) Why does C# have a 'C' in its name but looks almost exactly like Java? I also believed that a good programmer must know Java, C/C++, PHP for server programming, and Python just to prove you're smart. I swear this is a phase that I literally went through.

This was because when you've just started coding, for some reason there's this notion of being defined by the programming languages you know and the libraries you use. I'm sure that was greatly influenced by the "Top 10 best languages to learn in 201X" or "Language X is dead, here's why", even "Programming languages used by Facebook" articles that I actively looked for! just so that I don't get left behind in the industry.

Of course, a lot changed in the way I view tech and my career but what I felt about C# or anything related to it never changed, until about 6-7 months ago. See, at work, they use a shit ton of .NET (or dotnet. I'm still getting the hang of this) so I'm learning it now. A few months ago, I completed a 'Basics for beginners' udemy course. It was fine I guess🙄 but learned a lot of cool stuff 🤗

Now I'm creating a project so that I learn more of this freaky stuff. Enter .NET Core 3! The most overwhelming piece of framework I've ever encountered (this year. I have to be clear on this). I have never given up so many times but come back to try again, in just a single week, ever for any project that I ever started to learn. When I finally got my thingie to give me a token for authentication, after days and nights of struggle, I ran the most satisfyingly powerful git command known to mankind

git commit -m 'Initial commit'

I was happy. Then I had my supper while rereading up on what I've implemented and that's when I saw it

The masterpiece

private User GetUserByToken(string token)
{
    var user = (from u in _context.Users
        join t in _context.Tokens
            on u.Id equals t.UserId
        where t.Body == token
        select u).SingleOrDefault();

    return user;
}

It's beautiful isn't it? I thought so too
I mean do you understand that the last time I saw something this cool was when I saw JSX for the first time, which looked so confusing but really not so trivial after some time of use. My brain doesn't have to context switch between application code and database scripts but the thing just works seamlessly. And the syntax highlighting plus the IntelliSense! I am stunned.

If you're reading this and you do not understand WTF is going on here, it's okay, it's not your time yet. But later on in your life, you will see what I saw and you'll say "shit, that dude on dev.to wrote a weird post about this feeling I'm feeling right now".

Not convinced? Look again

Ok I knew contributing to open source was fun but no one told me it would be this easy :satisfied:

Sdu — Sat, 12 Oct 2019 22:24:08 +0000

I honestly didn't think I would be able to finish the hacktoberfest challenge, let alone in such short amount of time. Still I feel like I am not done participating.

I first heard of hacktoberfest last year when I had been a member of Dev.to for just a couple of months and struggling with getting my open source app off the ground. I focused on working on my own project because I believed to contribute to another person's or organisation's codebase you have to be super skilled. While asking for help with my own issues I was facing, another community member subbramanil opened a PR just for a single unit test file and took me through what the contribution was and why he was doing it, as confused and excited as I was. Here's one inspiring piece:

HactoberFest Challenge: Completed

Subbu Lakshmanan ・ Oct 30 '18

#hacktoberfest #android #opensource

A year later. Still I didn't want to contribute to anything because I felt I wasn't going to be good enough. I read so many posts everywhere about how people contributed even it was just a single line of documentation in a README.md and that really pumped me up to actually doing something. (I still didn't)

What got me to stop procrastinating about participating is the fact that everyone in my office was either already participating or being encouraged to. Plus I wouldn't want to see a bunch of beautiful hacktoberfest T-shirts at work knowing that I could've gotten one too but didn't do anything about it.

This past Friday, I found easy prey. I saw this

Add JSDoc comments for better IDE support #27

LBBO posted on Oct 11, 2019

JSDoc comments can be added to most methods to clarify not only their purpose and usage, but also their parameter's expected types. Since this project is not written in TypeScript, IDEs could use these comments instead in order to provide useful code completion etc.

Please direct any PR towards the refactor-everything branch and only work on lib/netflix2.class.js as this is soon going to replace lib/netflix2.js.

View on GitHub

The thing is, I've been writting comments all my live (minus the years I didn't know about programming) I mean how hard can it be?
I submitted a pull request, then BOOM!! 1/4 PRs for hacktoberfest was done. I was so exited that I submitted 2 more pull requests to other repos in one day.

As a bonus to myself, I submitted a pull request to the Dev.to android project.

forem / DEV-Android

DEV Community Android App

DEV Android 💝

This is the official repository for the dev.to's Android app.

Design ethos

DEV Android is an WebView based application. This application is inspired by Basecamp's approach. We will grow to include more native code over time.

By leveraging webviews as much as possible, we can smoothly sync up with our web dev work. And where it makes sense, we can re-implement certain things fully native, or build entirely native features. Life's a journey, not a destination.

Contributions

We expect contributors to abide by our underlying code of conduct. All conversations and discussions on GitHub (issues, pull requests) and across dev.to must be respectful and harassment-free.

System Requirements

You will need to have Android Studio 3.5 or up installed.

Usage

$ ./gradlew tasks --group=custom
------------------------------------------------------------
Tasks runnable from root project
------------------------------------------------------------

Custom tasks
------------
androidTest - Run android instrumentation tests
hello - Hello World task

…

View on GitHub

Flutter Dependency Injection

Sdu — Sat, 07 Sep 2019 09:41:21 +0000

cover image source

Lately I've been fascinated with code sharing between web and mobile. Obviously there are many ways one can write code to be shared among platform and the phrase 'code sharing' can imply quite a number of things. The one that intrigued me the most was with Flutter, AngularDart (I'll continue referring to this as ngDart) and the BLoC pattern.

To demonstrate my findings I took the flutter pre built counter app and implemented it in ngDart. I did try to make it as identical as possible but I'm lazy and I wasn't very much focused on the aesthetics. Check out the repo here

To run the flutter app, open the flutter project folder and either use your IDE shortcut or in the terminal, do
> flutter run
To run the angular app, it's almost same thing, but the command is
> webdev serve

You'll see that with ngDart, dependency injection framework is no issue as it's built in but with Flutter, I had to shop around for the solution that looks like it fits.

Solution 1

flutter_simple_dependency_injection
I found this package from the article I used to start off my code sharing example. I wouldn't have made the project if I didn't think that article although very informative it was rather complex when it came to the example.

Solution 2

Googles inject.dart repo
This seemed like the go to solution. Their README mentions charming fancy words like

Compile-time dependency injection for Dart and Flutter, similar to Dagger.

I was hooked, especially because I had just ported my open source android app to Dagger.
I immediately ported my example to use it instead, while doing so I couldn't throw off the bad feeling that came with using this package.

It isn't on the dart package registry pub.dev so there's a funky way you must use to add it to your project.
Their README has a note stating **This is not an official Google or Dart team project. while the repo is literally hosted by the Google org on github.
The issue tracker is disabled. That was all enough for me to look for another solution. I didn't even get to see this in action. I stopped in the middle of configuring it.

Solution 3

dependecies_flutter
While porting to this, I immediately felt comfortable. It was modular and felt native to the flutter Widget system. The author's examples we're also very easy to follow, I didn't have to google for a medium article just to understand how to use it.

I hope I don't get to Solution 4 because Solution 3 chased me away but rather because of what benefits my projects will be getting from the migration instead.

I got the job 💃

Sdu — Thu, 21 Mar 2019 09:29:15 +0000

This is just a follow-up to the post I wrote a while back.

I went to my first interview! It was terrifying.

Sdu ・ Feb 12 '19

#beginners #career #discuss

After that first interview, I went to another a few days later and got an offer from the second company on the spot. What I immediately got from that was, an interview goes both ways. As much as they are assessing you, you also have to be assessing them. Anyway, I declined an offer to be a front-end developer from this other company and came back to codeo to complete the recruitment process, that being a full day spent at their offices with the team and a second interview.

I started work officially on the 1st of March and I couldn't be more happier. If I were to tag each and everyone who posted here, the content that helped me prep, I wouldn't even know where to start. Thanks to everyone who is a part of dev.to and those that are always lending a helping hand to career toddlers like me. You know, I've even received emails of people pointing out typos in my resume that I'd overlooked.

I mean check this out

Do I Want To Work In This Company, or What Questions To Ask On An Interview

Elena ・ Nov 8 '17

#career #interview #job

I don't know how many times I read these questions, days before both my interviews at codeo. When they finally asked me "Alright, do you have any questions to ask us?" I was blank! This happened twice, when I was trying to recall questions that they haven't answered indirectly or that I haven't figured out already. At most I'd just say "No I don't have any, question 1, 2 and 3 were answered by this, that and such and such but thank you for the opportunity" as I said that, a funny question clouds my mind, it was so silly that I'd giggle while I was trying to speak, like an inner voice kept on shouting "ASK THEM WHERE DO I SIGN?"

Anyway, I'd talk about this forever, I just wanted to let you all know that I'm good now. I'm jobbing 🎉🎉🎉 (if that's a word)

I redid my portfolio site for the third time, this year alone!

Sdu — Fri, 22 Feb 2019 00:32:09 +0000

The last quarter of 2018 was the year dev.to was most influential in my career. More so great because I was doing my last year in varsity. I was inspired to start a project and actually finish it while following advice for projects to show off on my portfolio.

From Vue.js to a Jekyll generated 'noscript' site

I entered a year with a portfolio that had some fun animations powered by Vue.js, but as part of my resolutions this year, I wanted to start blogging. I took down my site, recreated it now with Jekyll and its default theme. No javascript whatsoever.

From default minima theme to more custom design

Ok, I think it is great that Jekyll provides minima as their entry theme, not too heavy and not too complicated to customize. I changed the home page to something I felt represented me the most. At some point, my portfolio site was opened on one job interview that I was in on a projector

Now this!

I created a new branch just for the redesign. I deleted everything on my repo and started with a new index.html file and worked my way up from there. And being unemployed 🤣, I've been in front of my laptop for more than 10 hours updating my site, and now writing this post minutes after pushing the changes.

View my incomplete portfolio here and tell me what you think. Of course, it's not complete yet, I need to add a section for my projects and a link to my resume. I also have to redesign pages for my blog posts. I would use any Jekyll theme but I feel that takes away my personality from the site.

What makes this even more fun is that I'm doing this while learning vim. People really need to check this article out, for beginners like me who were lowkey scared of taking that leap because of the "Exiting vim" jokes, exiting vim is actually wayyy easier than I thought 😳

Boost Your Coding Fu With Visual Studio Code and Vim

Jaime González García ・ Feb 10 '19

#vscode #vim #webdev #productivity

I almost forgot to mention the logo!

I made it with gimp. using material colors of course. Do you guys know about this material color picker? I use it all the time! Even with my portfolio design and graphics. I then exported my logo as a big .bmp file to trace with Inkscape for a smaller SVG.

I went to my first interview! It was terrifying.

Sdu — Tue, 12 Feb 2019 13:56:25 +0000

Terrifying in a good way. I've never been in an interview aligned with my career and I'm still a fresh graduate. The post is for a Junior QA Engineer, of course it's not development but I read up on the role thoroughly and I feel it's really important that I start with it. Its gonna teach me so much about ensuring code quality and maintaining standards of the organisation, which at some point developers tend to overlook.

I also want to get into a hobby of Test Driven Development. Which I feel would be inline with the culture of quality assurance. I'm highly interested in taking up the responsibility of the role so much that my nerves during the interview were intertwined with excitement.

By the way, I just completed my degree in Computer Science, so job hunting season kicked off in the beginning of this year. I'm constantly sending out applications and hoping for the best. Regardless of the decision that will be taken by my interviewers today, I learned a lot. My first experience of a cultural interview was awesome. I also found out that I'm quite good with office humour,apparently.

I took a lot of advice from posts here on dev.to and it helped that I'm a talkative person so the interview felt more like a conversation about me, more than anything else. A treasure that helped me through the process is a post by @emmawedekind

Article No Longer Available

Although typically cultural interviews aren’t as terrifying as coding interviews, interviewers can make or break your application.

I swear to God, half of my confidence came from it. In as much as I was beginning this journey, I felt prepared. Also being honest actually worked very well in my favour. I'm just still not sure how they received my humour 😑

Here's one thing that terrified me. I misread the time on my calendar by mistake, I thought I was coming in an hour early but turns out, I was JUST IN TIME. So already I was thrown off a bit. Props to being punctual 🤞. Also I don't think anyone likes seeing a whiteboard where an interview is to be conducted. Luckily not required at the time, but those few minutes of waiting for my interviewers to join me in the boardroom, I couldn't help but wonder which "searching algorithm" were they gonna ask for, just nerves messing me up I guess.

Anyway, I can't wait to get my first job in tech 🤞

SDP - A scalable size unit... To the rescue 😁

Sdu — Sun, 13 Jan 2019 00:14:11 +0000

My first 2019 post here on dev.to so happy new year and you're awesome 😎

I wrote an article here about my side project last year and the side effects were amazing 🙌 Downloads picked up a lot and I've been receiving great reviews.

Side project success 🎉

Sdu ・ Dec 15 '18

#showdev #android #kotlin

From the feedback the app was received on google play and emails, one issue stood out the most.

This is used as the cover image also 😐

Another review 🤨

Last screenshot, I swear 😑

I tinted the images to differentiate from the site background

Basically more and more people noticed the "little thing" I thought was "not an issue" text size on different screen sizes

I can't really recall how many requests I received about text size issues on smaller screen devices but it got me paranoid.

See, the app is a minimalist launcher that allows you to choose 5 apps to appear on your home screen and only displays a clock plus your selection. The problem is on smaller screens, app text would overlap with the clock 😫

I tried creating different dimens resources to target different densities but that was a disaster. I knew I would never cover every use case smoothly.

Until I came across

intuit / sdp

An Android lib that provides a new size unit - sdp (scalable dp). This size unit scales with the screen size.

SDP - a scalable size unit

An android lib that provides a new size unit - sdp (scalable dp). This size unit scales with the screen size. It can help Android developers with supporting multiple screens.

for text views please refer to ssp which is based on the sp size unit for texts.

Attention

Use it carefully! for example, in most cases you still need to design a different layout for tablets.

Example

Here is a single layout built using sdp:

And here is the same layout built using dp:

You can see that sdp scales with the screen size and the dp stays with the same size on all screen sizes.

Getting Started

To add sdp to your project (Using Android Studio and Gradle):

add implementation 'com.intuit.sdp:sdp-android:1.1.1' to your build.gradle dependencies block.

for example:

dependencies {
  implementation 'com.intuit.sdp:sdp-android:1.1.1'
}

See the sdp_example.xml to see how to use to the…

View on GitHub

And

intuit / ssp

Variant of sdp project based on the sp size unit.

SSP - a scalable size unit for texts

An android lib that provides a new size unit - ssp (scalable sp). This size unit scales with the screen size based on the sp size unit (for texts). It can help Android developers with supporting multiple screens.

This is the sibling of the sdp size unit that should be used for non text views.

Attention

Use it carefully! for example, in most cases you still need to design a different layout for tablets.

Example

Here is a single layout built using ssp:

And here is the same layout built using sp:

You can see that ssp scales with the screen size and the sp stays with the same size on all screen sizes.

Getting Started

To add ssp to your Android Studio project:

add implementation 'com.intuit.ssp:ssp-android:1.1.1’ to your build.gradle dependencies block.

for example:

dependencies {
  implementation 'com.intuit.ssp:ssp-android:1.1.1'
}

See the ssp_example.xml…

View on GitHub

I trusted these libraries for delivering a consistent ui in all homescreens of the hundreds of users who downloaded my app.

I truly design just one layout, use probably @dimen/_64sdp for a margin or text size and something like @dimen/_12ssp for an android:textSize that I want consistent across a lot of screen sizes.

It supports minimum sdk version 16, and I'll be testing for tablets too.

Be careful not to forget that the all screen sizes approach is not a solution for most ui design solutions.

Happy coding

DEV Community: Sdu

null vs undefined? What to choose? What to use?

null

undefined

What to choose? What to use?

Firebase authentication you can eject, used with any backend

Why firebase?

Yea nah. You don't need firebase on your server.

How it all works

1. Ensuring that the the signature is valid

2. Validate the token payload claims

To sum up

Introducing purgitory. My first npm package :)

Introducing purgitory. My first npm package :)

Hacktoberfest is coming!

Hacktoberfest is coming!

So What's Hacktoberfest?

A few tips on how to find projects to contribute to

Creating an auto resizing textarea with Vue Composition API in 4 easy steps. I can't wait for Vue v3

Step 1

Step 2

Step 3

Step 4

C# and .NET Core Appreciation Post. The most beautiful piece of code I have ever seen... this month!

Disclaimer!

The masterpiece

Not convinced? Look again

Ok I knew contributing to open source was fun but no one told me it would be this easy :satisfied:

HactoberFest Challenge: Completed

Subbu Lakshmanan ・ Oct 30 '18

Add JSDoc comments for better IDE support #27

forem / DEV-Android

DEV Community Android App

DEV Android 💝

Design ethos

Contributions

System Requirements

Usage

Flutter Dependency Injection

Solution 1

Solution 2

Solution 3

I got the job 💃

I went to my first interview! It was terrifying.

Sdu ・ Feb 12 '19

Do I Want To Work In This Company, or What Questions To Ask On An Interview

Elena ・ Nov 8 '17

I redid my portfolio site for the third time, this year alone!

From Vue.js to a Jekyll generated 'noscript' site

From default minima theme to more custom design

Now this!

Boost Your Coding Fu With Visual Studio Code and Vim

Jaime González García ・ Feb 10 '19

I almost forgot to mention the logo!

Links

I went to my first interview! It was terrifying.

Article No Longer Available

SDP - A scalable size unit... To the rescue 😁

Side project success 🎉

Sdu ・ Dec 15 '18

intuit / sdp

An Android lib that provides a new size unit - sdp (scalable dp). This size unit scales with the screen size.

SDP - a scalable size unit

Attention

Example

Getting Started

And

intuit / ssp

Variant of sdp project based on the sp size unit.

SSP - a scalable size unit for texts

Attention

Example

Getting Started