openssl s_client -quiet -crlf -starttls smtp -connect mail.example.com:25
openssl s_client -starttls smtp -quiet -crlf -connect mail.example.com:587
openssl s_client -quiet -crlf -connect mail.example.com:465
openssl s_client -crlf -connect mail.example.com:143 -starttls imap -servername mail.example.com
Presentation by Dan Gebhardt at EmberCamp Chicago. September 16th, 2019.
Web workers bring a new layer of capabilities to web applications. Because workers operate on their own threads, they provide a way to perform processor-intensive tasks without affecting the responsiveness of an application. This talk will explore the different types of workers, including service workers and shared workers, and how to make the most of them in your Ember applications. We'll discuss the capabilities available to workers and explore different use cases, including progressive web apps.
This is a short tutorial on using podman to run X11 applications. This need often arises when one has to run X11 applications on distros such as Silverblue, when the application for instance has no Flatpak and one doesn't want to install the particular app on their host OS (for instance for Silverblue this process would result in the need to layer a package and then reboot, something which understandably would get quite irritating after a while).
This guide was written because I don't particularly enjoy deploying Phoenix (or Elixir for that matter) applications. It's not easy. Primarily, I don't have a lot of money to spend on a nice, fancy VPS so compiling my Phoenix apps on my VPS often isn't an option. For that, we have Distillery releases. However, that requires me to either have a separate server for staging to use as a build server, or to keep a particular version of Erlang installed on my VPS, neither of which sound like great options to me and they all have the possibilities of version mismatches with ERTS. In addition to all this, theres a whole lot of configuration which needs to be done to setup a Phoenix app for deployment, and it's hard to remember.
For that reason, I wanted to use Docker so that all of my deployments would be automated and reproducable. In addition, Docker would allow me to have reproducable builds for my releases. I could build my releases on any machine that I wanted in a contai
| #!/usr/bin/env node | |
| import logPromise from '@quarterto/log-promise'; | |
| import assertEnv from '@quarterto/assert-env'; | |
| import jiraCreateVersion from '@quarterto/jira-create-version'; | |
| import path from 'path'; | |
| const commit = process.env.SOURCE_VERSION; | |
| const packagePath = path.resolve('package.json'); | |
| const {version, name} = require(packagePath); |
| import Ember from 'ember'; | |
| import hbs from 'htmlbars-inline-precompile'; | |
| import connect from 'ember-redux/components/connect'; | |
| var stateToComputed = (state) => { | |
| return { | |
| low: state.low, | |
| high: state.high | |
| }; | |
| }; |
Redux was developed to achieve hot reloading global state and state changing logic. To achieve that it was necessary for state changes to be run with pure functions and the state has to be immutable. Now you can change the logic inside your reducer and when the application reloads Redux will put it in its initial state and rerun all the actions again, now running with the new state changing logic.
Cerebral had no intention of achieving hot reloading. Cerebral was initially developed to give you insight into how your application changes its state, using a debugger. In the Redux debugger you see what actions are triggered and how your state looks after the action was handled. In Cerebral you see all actions fired as part of a signal. You see asynchronous behaviour, paths taken based on decisions made in your state changing flow. You see all inputs and outputs produced during the flow and you even
All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.
Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.
elem.offsetLeft, elem.offsetTop, elem.offsetWidth, elem.offsetHeight, elem.offsetParent
| 'use strict'; | |
| module.exports = function CustomError(message, extra) { | |
| Error.captureStackTrace(this, this.constructor); | |
| this.name = this.constructor.name; | |
| this.message = message; | |
| this.extra = extra; | |
| }; | |
| require('util').inherits(module.exports, Error); |