| @media screen and (max-width: 991px) { | |
| /* Your responsive CSS */ | |
| } | |
| @media screen and (max-width: 767px) { | |
| /* Your responsive CSS */ | |
| } | |
| @media screen and (max-width: 479px) { | |
| /* Your responsive CSS */ | |
| } |
I created a crude comparison of the syntax of the various common Markdown extensions to have a better view on what are the most common extensions and what is the most widely accepted syntax for them. The list of Markdown flavors that I looked at was based on the list found on CommonMark's GitHub Wiki.
| Flavor | Superscript | Subscript | Deletion* Strikethrough |
Insertion* | Highlight* | Footnote | Task list | Table | Abbr | Deflist | Smart typo | TOC | Math | Math Block | Mermaid |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| GFM |
| command | usage | |
|---|---|---|
| git init | Creates an empty Git repository in the specified directory. | |
| git clone <repository name> | Clones a repository located at <repository name> onto your local machine. | |
| git add <directory> | Stages only the specified changes for the next commit. Replace <directory> with a <file> to change a specific file. | |
| git add . | Stages new files and modifications without deletions | |
| git add -A | Stages all changes | |
| git add -all | Equivalent to git add -A | |
| git add -u | Stages modifications and deletions without adding new files | |
| git add --update | Equivalent to git add -u | |
| git commit -m ”<message>” | Commits the staged snapshot. replace <message> with the commit message. |
Phoenix 1.4 ships with exciting new features, most notably with HTTP2 support, improved development experience with faster compile times, new error pages, and local SSL certificate generation. Additionally, our channel layer internals receiveced an overhaul, provided better structure and extensibility. We also shipped a new and improved Presence javascript API, as well as Elixir formatter integration for our routing and test DSLs.
This release requires few user-facing changes and should be a fast upgrade for those on Phoenix 1.3.x.
The mix phx.new archive can now be installed via hex, for a simpler, versioned installation experience.
To grab the new archive, simply run:
| # This is the target module which will be overwritten after dynamic compilation | |
| # You'll be using this to read configuration in your code. For instance, if you | |
| # have a configuration key called `:redis_timeout`, you could read it using | |
| # `MM.Config.get(:redis_timeout)` | |
| defmodule MM.Config do | |
| # we use a default implementation which raises an error when our code tries | |
| # to read configuration before it is compiled. | |
| def get(_key), do: raise("Config has not been compiled yet!") | |
| end |
| defmodule MdToolbox.Api.SoapMethod do | |
| alias __MODULE__ | |
| alias MdToolbox.Api.Request | |
| @doc "Builds the request from params" | |
| @callback build_request(params :: list()) :: map() | |
| @doc "Parses the request's response into data" | |
| @callback parse_response(request :: Request.t()) :: Request.t() |
| # use Mix.Config | |
| # config :constants, | |
| # :some_string: "some_string", | |
| # :range_i_like: 1..5, | |
| # :a_map: %{letters: ~w(a b c)} | |
| defmodule Constants.Macro do | |
| # Take code and convert to AST | |
| # Inject name into quoted expression as the name of the macro |
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
How do you send information between clients and servers? What format should that information be in? What happens when the server changes the format, but the client has not been updated yet? What happens when the server changes the format, but the database cannot be updated?
These are difficult questions. It is not just about picking a format, but rather picking a format that can evolve as your application evolves.
By now there are many approaches to communicating between client and server. These approaches tend to be known within specific companies and language communities, but the techniques do not cross borders. I will outline JSON, ProtoBuf, and GraphQL here so we can learn from them all.
If you want a run-down of the 1.3 changes and the design decisions behidn those changes, check out the LonestarElixir Phoenix 1.3 keynote: https://www.youtube.com/watch?v=tMO28ar0lW8
To use the new phx.new project generator, you can install the archive with the following command:
$ mix archive.install https://github.com/phoenixframework/archives/raw/master/phx_new.ez
Phoenix v1.3.0 is a backwards compatible release with v1.2.x. To upgrade your existing 1.2.x project, simply bump your phoenix dependency in mix.exs: