DEV Community: Ugur Tekbas

Github GraphQL API Query Examples

Ugur Tekbas — Sun, 08 Oct 2023 20:50:50 +0000

Recently, I created a tiny app to browse public repositories on GitHub. And I've noticed there aren't many examples of Search queries out there, so I wanted to provide some examples with this post.

Let's start with a simple query:

search(
    query: "language:Kotlin forks:>10"
    type: REPOSITORY
    first: 5
    after: null
  ) {
    repositoryCount
    nodes {
      ... on Repository {
        name
        description
        stargazerCount
        forkCount
      }
    }
  }

We are using four parameters in the search query above. First one query is basically our search phrase, what kind of public repositories we want to search for. I chose repositories which contain Kotlin language and has more than 10 forks. You can change your phrase as you wish, it uses same structure in Github's search page. type is what we want to search, we used REPOSITORY value because we want to check out repos. We could also use issues, users or discussions. first is determine how many items we want from the top of the resulting list. after is used for pagination; it’s not required, but I wanted to use it just to demonstrate some paginated queries later.

Next let's take a look at what kind of information we are requesting. repositoryCount is an interesting one, it tells us the number of results for this specific search. We will soon see in the response that there are 7247 repositories on Github matches our "language:Kotlin forks:>10" phrase. The reason we used ... on Repository line is because search result could be different types such as discussions, issues, users. We are only interested in repositories so we used that, more about Fragments later.
For Repository object we get name, description, number of stars and forks it has, pretty straight forward basic information about particular repository.

Let's see the results:

{
  "data": {
    "search": {
      "repositoryCount": 7247,
      "nodes": [
        {
          "name": "kotlin",
          "description": "The Kotlin Programming Language. ",
          "stargazerCount": 45957,
          "forkCount": 5672
        },
        {
          "name": "okhttp",
          "description": "Square’s meticulous HTTP client for the JVM, Android, and GraalVM.",
          "stargazerCount": 44551,
          "forkCount": 9224
        },
        {
          "name": "architecture-samples",
          "description": "A collection of samples to discuss and showcase different architectural tools and patterns for Android apps.",
          "stargazerCount": 43189,
          "forkCount": 11579
        },
        {
          "name": "shadowsocks-android",
          "description": "A shadowsocks client for Android",
          "stargazerCount": 34022,
          "forkCount": 11640
        },
        {
          "name": "fanqiang",
          "description": "翻墙-科学上网",
          "stargazerCount": 32131,
          "forkCount": 6473
        }
      ]
    }
  }
}

As you can see our query works like a charm 🥳.
We received 5 repos as requested and all the details they have. Whenever I do searches on Github I stumble upon interesting repos like fanqiang here.

You can run queries by yourself and check out the data using Github's Explorer tool.

📚 More data

Let's extend our query by requesting more fields. We can use owner field to get repo owner's name, url field to get Github page url , some important dates and also all the programming languages repo contains. Let's check out this extended version of our query:

search(
    query: "language:Kotlin forks:>10"
    type: REPOSITORY
    first: 5
    after: null
  ) {
    repositoryCount
    nodes {
      ... on Repository {
        id
        name
        description
        stargazerCount
        forkCount
        updatedAt
        createdAt
        url
        owner {
          login
        }
        languages(first: 3) {
          nodes {
            name
            color
          }
        }
      }
    }
    pageInfo {
      hasNextPage
      hasPreviousPage
      startCursor
      endCursor
    }
  }

If you noticed we requested a field called pageInfo in the new query. We can use that information to navigate different pages and to determine if there are more pages to paginate. Check out this gist for queries with pagination parameters.

📗 Using Fragments

So far our queries are working and we are retrieving the data we want. It's possible that our queries get longer and longer over time. Let's use Fragments and make our queries reusable and pretty.

Fragments are a way to define reusable sets of fields that can be included in multiple queries. They allow you to group fields together and give them a name, making your queries more organized, readable, and maintainable. Fragments help avoid duplication of field selections when you have common sets of fields that you want to include in multiple parts of your queries. Looking at our query we can easily define a fragment for main Repository object as following:

fragment Repo on Repository {
    id
    name
    description
    stargazerCount
    forkCount
    updatedAt
    createdAt
    url
    owner {
      login
    }
    languages(first: 3) {
      nodes {
        name
        color
      }
    }
  }

Now Repo fragment is ready to use in main query, in the mean time you can try to create another fragment for LanguageConnection where we request languages info for each repo.

Now let's look at the final version of our query:

search(
    query: "language:Kotlin forks:>10"
    type: REPOSITORY
    first: 5
    after: null
  ) {
    repositoryCount
    nodes {
      ...Repo
    }
    pageInfo {
        startCursor
      endCursor
      hasNextPage
      hasPreviousPage
    }
  }

Short and sweet 👌🏽
We used newly created Repo fragment and it's ready to use all other queries and mutations in the future.

You can find all the query examples with different parameters and pagination in this gist file. I hope this gives you a head start to write queries. If you have any questions/suggestions feel free to drop in the comments below.

This article is originally posted on my blog.

Say hi to me on Twitter!

Onboarding Remotely Best Practices

Ugur Tekbas — Sun, 09 May 2021 11:18:24 +0000

Onboarding is the official process of integrating new team members into an organization. It's a good spot to start everything on the right foot. Over the years, I've been lucky enough to introduce great engineers to my teams. In some cases I onboarded solely on our codebase, sometimes it was a tool we used frequently or it was just about the product and responsibilities. Regardless of focus area, our goal stays the same:

Enabling newly joined team members to contribute.

At the end of the process, onboardee (Yeap! There is such a word) should have clear answers to their questions, should feel confident and comfortable enough to kickstart their journey.

Remote working is becoming a strong norm, it's escalated with Corona and hopefully it will be permanent for many companies. It will be more and more common to onboard new members remotely in the future. I wanted to share my experience on welcoming new engineers during fully remote setup and to highlight what worked well within in the long run.

Before we begin it's safe to raise my assumption: My experience is based on cross-functional teams who work on dedicated parts of products with a huge active user base.

📚 Prepare visual documentation

I assume you already have a detailed documentation for your platform or domain in general, where you explain the tools, frameworks, patterns you make use of. If you don't, it will be wiser to start with that. I think onboarding through documentation is more efficient because it's scalable, quotable and iterable. I usually create sections with the topics I wanted to talk about, create special diagrams to help me explain concepts or architectures better. Stating the purpose of each layer, giving links to other detailed documentation areas are good practice. Something I noticed is that adding screen shots of the product helps a lot to associate code with product and features. Even recording some features to show user flow brings many advantages.

✔️ Draft a checklist

Having a short to-do list for the new team member gives a lead to start and creates sense of accomplishment. This list is just consist of small tasks that everybody needs to do when they join the team, such as; joining the common slack channels, requesting needed permissions for tools, joining certain trainings, finding a pairing buddy, joining to office tour etc. They can do them theirselves and cross them out the list.

🤝 Pair whenever

Pairing is such a secret weapon which should be used so often that it stops being secret anymore. You can also take advantage of pairing during onboarding process. Whenever possible, you can invite the new team member pair on tasks where you'll be the main driver and navigator, while onboardee is mostly observing. This might give more clarity on topics and ease the overall onboarding journey.

📆 Spread meetings over a period

One of the things I really like to do is spreading onboarding meetings over a wider period of time. Keep in mind that this is not the only onboarding they are attending, in first weeks they probably have organizational and cultural ones too. Instead of discussing the codebase for 4 hours in one day, I setup multiple slots spread over the days where I get together with the onboardee and have a talk for about an hour. As this gives them space and time to think about the topics we discussed, it also allows me to direct onboarding process better. I usually setup the last meeting as AMA (ask-me-anything) style, where onboardee can address any kind of questions, technical, organizational or even personal.

⌚ Give them time

Once I joined a team where many concepts were new to me, I had to learn a new language and how to use bunch of tools. This situation quickly becomes overwhelming; good way to solve it is having enough time to digest new chunks of information and to experiment enough with new tools. Luckily at the time, my team gave me enough time and space, this allowed me start contributing when I felt comfortable, removed the pushy feeling, resulted with the best possible outcomes for the team and product. I believe that's a good practice instead of expecting onboardee to start with a small bug ticket in few days.

💬 Ask for feedback

Feedback is a gem, having a habit of asking feedback often brings tremendous benefits. So it's important we don't miss this step and ask for feedback about the onboarding and overall process when it's completed. Additionally, usually after 3 months, I ask for an extra feedback. At that point, they have worked together with the team for a while, completed certain tasks, understood how team and product works, thus they can look back in retrospective and bring ideas about what could be improved. This will help to iterate all the practices above and most importantly it will benefit the next onboardee (yes I like this word) a lot.

Onboarding is a continuous process during a team member's first year. Remote or not, having an efficient onboarding process have long-term benefits: increased productivity, robust product, better team member retention, reduced anxiety, accurate expectations.

I hope practices above helps you as well. Do you have any other ideas how to make onboarding more efficient? Let me know in the comments below!

This article is originally posted on my blog.

Say hi to me on Twitter!

Lessons I’ve Learned by Teaching Programming - After Party

Ugur Tekbas — Sun, 07 Jun 2020 18:29:40 +0000

Let’s talk about what we can do after our course is done. After careful preparation and effective execution, now we’re at the end of the course. In this part, We’ll talk about what we can do to help our students after every lesson or when the course is completed. This will make our students still benefit from our course and experiences, even after their active learning days are over.

This is the last part of series focused on teaching programming. You can read the first part about preparation here and second part about practices during the lessons here.

After Party

This is it, you made it! There were ups and downs, lots of bugs and questions but you managed to overcome them all as a team. Now it’s time make the course as beneficial as possible for your students for the future challenges.

What it takes is what they got

Make sure your students understand that just because the course is over doesn’t mean they should to stop learning or building. Encourage them to use what they’ve learned, do more research and keep learning.

Give them product ideas, this will make it easier for them to start building. It could be a personal website, a simple mobile application, a blog about recycling or landing page of their long planned side hustle. Make them feel confident enough to start coding with what they know, show them what it takes is all they got.

Show them you can do it.(image source)

Retrospective

Do this at the end of every day. Ask them what they liked about the lesson, what they didn’t, if there is anything they wish to change or add. Remember you already created an open environment so they’ll be willing to share their candid thoughts with you. Try to adopt new ideas to your lessons on the go, make everybody benefit from what you teach equally.

Make everything accessible

Probably the first request you’ll receive will be sharing the code you write in the lessons. Make it even better and share everything about the course with them - make everything easily accessible. List the content of the course and what you did right after course. This can be a list of the topics, the exercises you gave during the lesson, homework, your retrospective action items etc. Upload everything to Github (or Gitlab or Bitbucket) and BAM! You just taught them about Git.

This is a celebration

It’s been a rough patch but they did it! Show them their dedication and hard work deserve a celebration. Go out together to have dinner, do a beer night. In Corona times I was only able to prepare a cocktail and make a toast to them, however it was enough to get all of us into celebration mood.

This was the last piece of the entire course. Being approached by some of the students days after our course showed me it was quite rewarding to follow tips above.

What do you think about the tips above? Do you have any different ideas how to make teaching programming better? Let me know in the comments below!

This article is originally posted on my blog.

Say hi to me on Twitter!

Lessons I’ve Learned by Teaching Programming - Show Time

Ugur Tekbas — Mon, 25 May 2020 21:17:28 +0000

Let’s continue our journey of teaching programming. In the previous post we talked about preparation and what we can do before starting the actual course. In this post we’ll get into some ideas and practices we can use during the lessons.

This is the second part of series focused on teaching programming. You can read the first part here.

Show Time

How you deliver knowledge is as important as the knowledge itself. You can use some technics and methodologies which will clear most of the question marks for students. Some of the methods below that I planned prior the lessons and some of them I came up after. As long as it works for the students, it’s totally fine to change, add or discover different ways during the whole course.

Now you’re prepared and here you are, stage is yours!

Keep it simple

Like in one of the most underrated software principles, keep it very simple when you’re explaining new concepts or languages. Associate the concept with something concrete from real life. This will make the subject less scary and easier to understand for your students.

This is the image I created to explain what those languages do, in simplest way.

You can also apply the “explain it to me like I’m 5 years old” rule. Don’t worry people won’t mind, they just want to understand things.

Another advice would be: don’t give examples right away. Make them understand it first then do a general example which covers the topic. This way you also avoid squeezing the topic only in one example which might limit the way they are looking at it.

Practice makes it perfect, practice makes it amazing

It’s very important to make students practice right on the spot. With exercises they learn way more than with any other method. Power of practicing within the lessons is underrated…or I just didn’t know about it.

It might feel weird to give students a block of few 15 minutes to work on their own when you have limited time for a session, but it is definitely worth it. First keep the exercise simple, let them try to figure things out, and watch how they approach the problem. You can literally sneak up to their monitor and talk about their approach. After 10-15 minutes, show the solution with some live-coding, where they can easily follow. If there are multiple solutions to the problem, you can show a few different approaches. As a last step, show them a real life example about the exact practice. It could be adding a nice footer to your website or using a random number function in JavaScript.

If you apply the 10000 hours rule, your students need to practice outside of the course too, it’s called “Homework”. Coming up with good homework is really hard (shout out to all my former teachers out there who came up with creative homework when I was studying). I consider three things while preparing a homework:

Including the subjects we learned in the last lesson
Making it useful so that they can easily imagine a different implementation for their different ideas
Making it challenging

During my first course, I noticed it’s good to have continuous homework rather than creating a new one every time. I call it lego-style homework (I literally made that up). What you do is giving small pieces of homework, that fulfill the three characteristics above, after the first lesson, and in every lesson after that you add new parts to this project. At the end of the course, students will have a useful product which is completely built by them.

When I was teaching web development, I asked my students to come up with a website idea, create their first html file, give it a title and put a headline in the middle of the page. After learning about different tags (like link, image etc.) I asked them to create a top menu bar and navigate to different pages. Following that, I asked them to create a footer, put images in the centre of their page, create columns, and write long paragraphs. When they learned how to use Bootstrap I asked them to replace columns by using grids, to style their site using CSS, and to add a form to their contact page.

I also asked them to do research on specific topics, just to get the basic ideas and to understand that this is also part of programming, a huge part of it. I believe power of homework, it effects the learning process significantly, especially for practice-heavy fields, such as coding.

Question or be questioned

Your students will want to ask you anything and everything which is absolutely fine. Your job is to make them feel totally relaxed about asking questions. Show them they can stop you and ask questions any time, no matter how silly or simple they are.

(image source)

You can do this by repeating the sentence “Do you have any questions?” every time after explaining something or asking them questions during lessons to see if they are clear of any confusion. You can also show them how to get answers themselves which is simple googling. Demonstrate how to search for the usage of an attribute or documentation by just googling in front of their eyes, and guide them to the wonderland of StackOverflow.

Give them a break

Not joking! :) Small breaks are part of the lesson. It helps them to refresh and take a deep breath before solving that annoying bug. At my first lesson, I was so focused on our topics that I forgot to give a break. That was the first thing we discussed at the end of the day, at our daily retro.

Have fun

It’s essential! Try to make it fun for anyone who attends the lessons. It’s already hard enough to learn new things, so make sure it’s fun. Create a comfy, easy environment and a soft language to follow effortlessly.

There are programming-related games where you can have fun while testing your coding skills. You can play them in the class together with your students or give them as homework.

These are the main practices I’ve followed for my course. I’ve received good feedback during and after the lessons as we discussed more about our approaches end of every day.

What do you think about the methods above? Do you have any different practices you can apply for the best teaching experience? Let me know in the comments below!

This article is originally posted on my blog.

Say hi to me on Twitter!

Lessons I’ve Learned by Teaching Programming

Ugur Tekbas — Wed, 13 May 2020 09:54:42 +0000

I have been working as a software developer for almost a decade. During this time, I often found myself explaining technical stuff to my pears, onboarding junior developers or having to explain tech-related topics to non-tech people. Even though I never received an education or training about teaching, I thought of myself as being good at explaining complex stuff in a simple way. I considered teaching programming but never tried to switch to that track until recently. Beginning of the year, I wanted to have this kind of experience and contacted HCS for a possible trainer role. First meetings were pretty smooth and after a trial lesson, we agreed that I will be taking care of web development course.

After completing my first course with amazing people, I started reflecting on the experience. As much as it was very rewarding and successful, there were things to improve. Attempting to write down some suggestions for myself led to this post.

  Without further ado, here are some of my ideas about teaching programming (or maybe just about teaching in general):

To make this post easier to read, I divided original article into three parts. This one is focused on preparation phase prior to courses.

Are you ready?

This part is for the things you should do before the course starts. As soon as your course is set and planned, you can encourage yourself to step into preparation.

Know your audience

You need to know who your target audience is. This will change the whole content and method of your course. Of course there is a certain group of customers to whom the courses are aimed at - you know this from the beginning - however not all participants will be in the same level. So it’s a good start to know your students’ level.  

You can do this simply by sending a small survey where you ask certain questions, like if they’ve ever coded before, what they think their level is on certain languages etc.

Creating a skill matrix would also work for this purpose.

List your ingredients

In short, you need to know which topics you’ll talk about in the particular session. Going through the content you have planned for yourself creates a big advantage. It allows you to see if your topics are overflowing your time or if you have too little to go over that day. Essentially it allows you to plan your time sufficiently.

Ingredients matters.(image source)

Say hello to your new friends

The best way to break the ice is to welcome your new friends for the tough journey prior to the first lesson. This will create the communication channel which hopefully lasts longer, maybe even after the end of the course.

Choose your preferred channel (could be email, slack) and show them it’s ok to contact you anytime they need you. 

You can also use this opportunity to hint to them what you’ll start working on, at the first lesson and ask them to install required tools or do some reading related to upcoming topics. This will save you so much time especially for the first class.

Prepare homework and exercises

We will go into the importance of giving exercises during the lessons in the following section but you should know that you will need to give many exercises during the sessions and always give homework at the end of every day. Therefore it’s a good practice to prepare them before the lessons according to the topics you’ll cover.

It would be a great idea to give lego style homework that will create a tiny product, tool or website in the long run. For example, you can start building a website and with every homework you build one part of the site by using what you taught in the lessons. This will motivate the students and show them they can built real stuff with what they just learned.

Build meaningful homework with lego style.(image source)

Also don’t forget to challenge them with every homework you give. It could be even something you haven’t taught yet, it’s always good to push them a little bit more than usual. Isn’t this also how a developer’s life looks like? One challenge after another… Anyway, let’s keep it on track.

This is it to get in shape for the course. After following the titles above, I easily welcomed the participants and had a quite productive first lesson.

What do you think about the preparations phase? Do you have any recommendations? Let me know in the comments below!

This article is originally posted on my blog.