$ echo 'gem "webpacker"' >> Gemfile
$ bundle install
$ rails webpacker:install
$ yarn add bootstrap@4.0.0-beta jquery popper.jsdiff --git a/config/webpack/environment.js b/config/webpack/environment.js
index d16d9af..86bf1a7 100644$ echo 'gem "webpacker"' >> Gemfile
$ bundle install
$ rails webpacker:install
$ yarn add bootstrap@4.0.0-beta jquery popper.jsdiff --git a/config/webpack/environment.js b/config/webpack/environment.js
index d16d9af..86bf1a7 100644| extern crate ring; | |
| use ring::aead::*; | |
| use ring::pbkdf2::*; | |
| use ring::rand::SystemRandom; | |
| fn main() { | |
| // The password will be used to generate a key | |
| let password = b"nice password"; |
Using perf:
$ perf record -g binary
$ perf script | stackcollapse-perf.pl | rust-unmangle | flamegraph.pl > flame.svg
NOTE: See @GabrielMajeri's comments below about the
-goption.
Within GitHub it is possible to set up two types of SSH key - account level SSH keys and and repository level SSH keys. These repository level SSH keys are known in GitHub as deploy keys.
Deploy keys are useful for deploying code because they do not rely on an individual user account, which is susceptible to change, to “store” the server keys.
There is, however, an ‘issue’ with using deploy keys; each key across all repositories on GitHub must be unique. No one key can be used more than once. This becomes a problem when deploying to repositories to the same server with the same user. If you create two keys, the SSH client will not know which key to use when connecting to GitHub.
One solution is to use an SSH config file to define which key to use in which situation. This isn’t as easy as it seems.. you might try something like this:
| <%# Put this code snippet between the <head></head>-tags in your application layout and %> | |
| <%# replace 'UA-XXXXXXXX-X' with your own unique Google Analytics Tracking ID %> | |
| <%# ... %> | |
| <head> | |
| <%# ... %> | |
| <% if Rails.env.production? %> | |
| <script type="text/javascript"> | |
| (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){ | |
| (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o), |
| [Unit] | |
| Description=Shadowsocks Server | |
| After=network.target | |
| [Service] | |
| ExecStart=/usr/local/bin/ssserver -c /etc/shadowsocks/ss-config.json | |
| Restart=on-abort | |
| [Install] | |
| WantedBy=multi-user.target |
If a project has to have multiple git repos (e.g. Bitbucket and Github) then it's better that they remain in sync.
Usually this would involve pushing each branch to each repo in turn, but actually Git allows pushing to multiple repos in one go.
If in doubt about what git is doing when you run these commands, just
| require 'openssl' | |
| require 'base64' | |
| # ===== \/ sign ===== | |
| # generate keys | |
| key = OpenSSL::PKey::EC.new("secp256k1") | |
| key.generate_key | |
| public_key = key.public_key | |
| public_key_hex = public_key.to_bn.to_s(16).downcase # public key in hex format |
| /** | |
| * This are a collection of examples for C 201. | |
| * These combine concepts you may or may not be | |
| * familiar with and are especially useful for | |
| * students new to C. There is a lot of really | |
| * cool stuff you can do in C without any cool | |
| * languages. | |
| * | |
| * This is file in particular is an introduction | |
| * to fun function usage in C. |
| use libc::{c_char, c_int}; | |
| extern { | |
| #[allow(dead_code)] | |
| pub fn puts(str: *const c_char) -> c_int; | |
| #[allow(dead_code)] | |
| pub fn printf(format: *const c_char, ...) -> c_int; | |
| } |