See how a minor change to your commit message style can make you a better programmer.
Format: <type>(<scope>): <subject>
<scope> is optional
| # Generate a new key | |
| openssl genrsa -out server.key 2048 | |
| # Generate a new CSR | |
| openssl req -sha256 -new -key server.key -out server.csr | |
| # Check certificate against CA | |
| openssl verify -verbose -CApath ./CA/ -CAfile ./CA/cacert.pem cert.pem | |
| # Self Signed |
Davy Brion and Jef Claes were discussing whether or not you can have REST without HTTP. Is this another peanut butter and chocolate thing? I think it's hard to extract REST from HTTP because that is how it is defined. I mean quite literally how it is defined in Fielding's dissertation. REST, the term, is short for "representational state transfer" but it still specifically describes an architectural style of representing state transfer via the HTTP specification.
But what if we didn't let such a little thing like semantics get in our way here and only took REST for it's literal name definition and not as the specification laid out in Fielding's dissertation? What if REST only meant a representation of state transfers? I'm not muc
| package cz.tejnora.pokusy; | |
| import static org.hamcrest.CoreMatchers.is; | |
| import static org.hamcrest.MatcherAssert.assertThat; | |
| import java.util.Arrays; | |
| import java.util.Collections; | |
| import java.util.Iterator; | |
| import java.util.List; | |
| import java.util.concurrent.atomic.AtomicInteger; |