i386 : iPhone Simulator | |
x86_64 : iPhone Simulator | |
arm64 : iPhone Simulator | |
iPhone1,1 : iPhone | |
iPhone1,2 : iPhone 3G | |
iPhone2,1 : iPhone 3GS | |
iPhone3,1 : iPhone 4 | |
iPhone3,2 : iPhone 4 GSM Rev A | |
iPhone3,3 : iPhone 4 CDMA | |
iPhone4,1 : iPhone 4S |
For a brief user-level introduction to CMake, watch C++ Weekly, Episode 78, Intro to CMake by Jason Turner. LLVM’s CMake Primer provides a good high-level introduction to the CMake syntax. Go read it now.
After that, watch Mathieu Ropert’s CppCon 2017 talk Using Modern CMake Patterns to Enforce a Good Modular Design (slides). It provides a thorough explanation of what modern CMake is and why it is so much better than “old school” CMake. The modular design ideas in this talk are based on the book [Large-Scale C++ Software Design](https://www.amazon.de/Large-Scale-Soft
FWIW: I (@rondy) am not the creator of the content shared here, which is an excerpt from Edmond Lau's book. I simply copied and pasted it from another location and saved it as a personal note, before it gained popularity on news.ycombinator.com. Unfortunately, I cannot recall the exact origin of the original source, nor was I able to find the author's name, so I am can't provide the appropriate credits.
- By Edmond Lau
- Highly Recommended 👍
- http://www.theeffectiveengineer.com/
This is a compiled list of falsehoods programmers tend to believe about working with time.
Don't re-invent a date time library yourself. If you think you understand everything about time, you're probably doing it wrong.
- There are always 24 hours in a day.
- February is always 28 days long.
- Any 24-hour period will always begin and end in the same day (or week, or month).
<? | |
# MIT license, do whatever you want with it | |
# | |
# This is my invoice.php page which I use to make invoices that customers want, | |
# with their address on it and which are easily printable. I love Stripe but | |
# their invoices and receipts were too wild for my customers on Remote OK | |
# | |
require_once(__DIR__.'/../vendor/autoload.php'); |
If you use server rendering, keep in mind that neither useLayoutEffect
nor useEffect
can run until the JavaScript is downloaded.
You might see a warning if you try to useLayoutEffect
on the server. Here's two common ways to fix it.
If this effect isn't important for first render (i.e. if the UI still looks valid before it runs), then useEffect
instead.
function MyComponent() {
https://gist.github.com/ljharb/58faf1cfcb4e6808f74aae4ef7944cff
While attempting to explain JavaScript's reduce
method on arrays, conceptually, I came up with the following - hopefully it's helpful; happy to tweak it if anyone has suggestions.
JavaScript Arrays have lots of built in methods on their prototype. Some of them mutate - ie, they change the underlying array in-place. Luckily, most of them do not - they instead return an entirely distinct array. Since arrays are conceptually a contiguous list of items, it helps code clarity and maintainability a lot to be able to operate on them in a "functional" way. (I'll also insist on referring to an array as a "list" - although in some languages, List
is a native data type, in JS and this post, I'm referring to the concept. Everywhere I use the word "list" you can assume I'm talking about a JS Array) This means, to perform a single operation on the list as a whole ("atomically"), and to return a new list - thus making it mu