An introduction to curl
using GitHub's API.
Makes a basic GET request to the specifed URI
curl https://api.github.com/users/caspyin
ּ_בּ | |
בּ_בּ | |
טּ_טּ | |
כּ‗כּ | |
לּ_לּ | |
מּ_מּ | |
סּ_סּ | |
תּ_תּ | |
٩(×̯×)۶ | |
٩(̾●̮̮̃̾•̃̾)۶ |
<!DOCTYPE html> | |
<!-- This is the shortest Image Uploader ever :) | |
And you can even make it shorter if you don't | |
want all the drag'n drop thing. --> | |
<!-- | |
AUTHOR: @paulrouget <paul@mozilla.com> | |
LICENSE: |
An introduction to curl
using GitHub's API.
Makes a basic GET request to the specifed URI
curl https://api.github.com/users/caspyin
The count of contributions (summary of Pull Requests, opened issues and commits) to public repos at GitHub.com from Wed, 21 Sep 2022 till Thu, 21 Sep 2023.
Only first 1000 GitHub users according to the count of followers are taken. This is because of limitations of GitHub search. Sorting algo in pseudocode:
githubUsers
.filter(user => user.followers > 1000)
I just had to set up Jenkins to use GitHub. My notes (to myself, mostly):
For setting up Jenkins to build GitHub projects. This assumes some ability to manage Jenkins, use the command line, set up a utility LDAP account, etc. Please share or improve this Gist as needed.
⇐ back to the gist-blog at jrw.fi
Or, 16 cool things you may not have known your stylesheets could do. I'd rather have kept it to a nice round number like 10, but they just kept coming. Sorry.
I've been using SCSS/SASS for most of my styling work since 2009, and I'm a huge fan of Compass (by the great @chriseppstein). It really helped many of us through the darkest cross-browser crap. Even though browsers are increasingly playing nice with CSS, another problem has become very topical: managing the complexity in stylesheets as our in-browser apps get larger and larger. SCSS is an indispensable tool for dealing with this.
This isn't an introduction to the language by a long shot; many things probably won't make sense unless you have some SCSS under your belt already. That said, if you're not yet comfy with the basics, check out the aweso
/* Copyright 2013 Google Inc. | |
Licensed under Apache 2.0: http://www.apache.org/licenses/LICENSE-2.0.html */ | |
package com.example.latlnginterpolation; | |
import android.animation.ObjectAnimator; | |
import android.animation.TypeEvaluator; | |
import android.animation.ValueAnimator; | |
import android.annotation.TargetApi; | |
import android.os.Build; |
For this configuration you can use web server you like, i decided, because i work mostly with it to use nginx.
Generally, properly configured nginx can handle up to 400K to 500K requests per second (clustered), most what i saw is 50K to 80K (non-clustered) requests per second and 30% CPU load, course, this was 2 x Intel Xeon
with HyperThreading enabled, but it can work without problem on slower machines.
You must understand that this config is used in testing environment and not in production so you will need to find a way to implement most of those features best possible for your servers.
When working with Git, there are two prevailing workflows are Git workflow and feature branches. IMHO, being more of a subscriber to continuous integration, I feel that the feature branch workflow is better suited, and the focus of this article.
If you are new to Git and Git-workflows, I suggest reading the atlassian.com Git Workflow article in addition to this as there is more detail there than presented here.
I admit, using Bash in the command line with the standard configuration leaves a bit to be desired when it comes to awareness of state. A tool that I suggest using follows these instructions on setting up GIT Bash autocompletion. This tool will assist you to better visualize the state of a branc