Here’s what I wrote on this (along with a small library to handle this problem): https://lisper.in/javascript-date
390 karma · joined April 6, 2009
Here’s what I wrote on this (along with a small library to handle this problem): https://lisper.in/javascript-date
- So you start work on a new branch, and reach a checkpoint. Create a new commit with "git commit".
- Continue working, and when you reach the next checkpoint, create another commit. But this time, use "git commit --amend". Contrary to what the flag says, this doesn't modify the previous commit, instead it modifies your commit history and replaces the last commit with a new one[1]. So instead of having two new commits in your branch's history, you only have one.
- Repeat the process until you have something worth pushing to the remote.
- Once you've pushed to remote, remember to not make any further modifications to your git history[2] i.e. going forward, create a new commit and only then run "git commit --amend".
Now, there's an obvious question here: if "git commit --amend" keeps replacing the last commit with a new one, what happens when you mess things up and want to revert to NOT the last checkpoint, but some checkpoint before that?
The trick here that git has up its sleeve is called "git reflog". You see, while "git commit --amend" replaces the last commit in your branch's history with a new one, the older commit is not actually gone, its still there. And you can see all of them with "git reflog". Basically "git reflog" returns every commit at which the local HEAD (i.e. the commit checked out in your working directory) has been. So none of the commits that you replaced with --amend are actually lost, and you can find them all in the reflog.
Restoring to an older checkpoint becomes as easy as running "git reset --hard <previous-commit-id>", or if you want to play safe, "git checkout -b <new-branch-name> <previous-commit-id>".
Hope this helps!
Notes:
1. By design, a commit, or in fact most objects in git cannot be modified. They are immutable.
2. Basically you can play with git history as long as it is private to you and not shared with others. But the moment you push it to a remote you share with others it's no longer private and you must not modify that history anymore. Read Linus's note on keeping a clean git history: https://www.mail-archive.com/dri-devel@lists.sourceforge.net...
Yeah, that would help. I'll add this.
> Also, adding spot pricing would be SUPER helpful!
Unfortunately spot pricing is not available in the bulk pricing API, which is what I am using here. But there does seem to be a separate API to get the spot pricing history - I will try to use it.
I wonder if it’s any good now. Haven’t looked at it in years.
Perhaps Nix might help here, but I've never used it, so can't say for sure.
Fun fact: the restarts based CSV parser was based on some real world work me and a colleague had done for an online travel portal. I wrote about it here: https://www.reddit.com/r/lisp/comments/7k85sf/a_tutorial_on_...
If the answer to these questions is no, then Cloudflare’s reasons for blocking ECS (ie privacy) carry weight. Otherwise no.
I don’t want to take away from your other point but this is not so trivial for the hundreds of millions living in low lying countries like Bangladesh.
> I'll remain a part of HIBP. I fully intend to be part of the acquisition, that is some company gets me along with the project. HIBP's brand is intrinsically tied to mine and at present, it needs me to go along with it.
Cloudfront’s pricing can absolutely bite you if you are not careful. Which is one of the reasons why I prefer Cloudflare over it.
IMO it is the most value for money (i.e. time and convenience) debugging tool I've used till now. Simply write (TRACE function1 function2 ...) in the REPL and you will get a nicely formatted output of arguments passed and value(s) returned for each invocation of the given functions. Another nice feature is that a deeper an invocation is in the stack the more it is indented -- so recursive functions are fairly easy to debug too.
You can't use it for everything but its sufficient most of the time.
PySnooper looks good, but it is inconvenient in a couple of ways:
1. It prints every line of the traced function -- most of the time this is overkill and not what one needs. 2. To snoop on a function you need to modify the source file. Not a deal breaker but you still have to remember to revert this.
So glad I have uBlock Origin.
1. As the article mentions, in some cases these apps end up leaking sensitive data like credit card detail and passwords. Generally, if you are taking snapshots of the user's screen instead of sending text metrics, it becomes much harder to mask sensitive data at all times.
2. The bigger issue is that these services generally use third parties to record this, and their privacy policy is a big problem. For example, Glassbox explicitly mentions that it will share end user personal data with their "enterprise" clients (which I am guessing are basically ad companies):
> From time to time, GLASSBOX grants certain of its enterprise clients a license or other rights to GLASSBOX’s proprietary software products and solutions (the “GLASSBOX Solutions”). Through their use of these GLASSBOX Solutions and/or through other means, enterprise clients of GLASSBOX may get access to, collect and use: (i) End User non-personally identifiable information; and (ii) End User Personal Data.
> There are also times when we will combine such information with additional non-personal or de-identified information we obtain from other companies as well as End User Personal Data, in order for our enterprise clients to market directly to a certain person subject to requirements of applicable law. We typically analyze this information and organize it into user groups and audiences, based on factors such as age, gender, geography, interests and online actions. We and our enterprise clients then use these user groups and audiences, along with information about the possible relationships among different browsers and devices, to design and deliver customized advertising campaigns or other relevant content.
That said, even in Common Lisp I think its only CLISP (among the free implementations) that gives the correct answer for long floats.
CLISP:
[1]> (- 9999999999999999.0L0 9999999999999998.0L0)
1.0L0
SBCL, CMUCL and Clozure CL: * (- 9999999999999999.0L0 9999999999999998.0L0)
2.0d0
The standard only mandates a minimum precision of 50 bits for both double and long floats, so there's no guarantee that using long floats will give the correct answer, as we can see.http://www.lispworks.com/documentation/HyperSpec/Body/t_shor...
https://github.com/thednp/bootstrap.native
It supports most (if not all) of bootstrap’s components, and works well enough that even large-ish projects can do without bootstrap.js (which needs jquery).
I wonder how Linus found him - was he an early contributor to Git?
Several observations recorded in the Project Zero report about CF's response were problematic:
"I had a call with cloudflare, and explained that I was baffled why they were not sharing their notification with me."
"They gave several excuses that didn't make sense, then asked to speak to me on the phone to explain. They assured me it was on the way and they just needed my PGP key. I provided it to them, then heard no further response."
"I can already see that the (huge) list does not contain many pages that still have cached content from before the bug was fixed."
"Cloudflare did finally send me a draft. It contains an excellent postmortem, but severely downplays the risk to customers."
Granted, I have not been keeping up with what has changed at CF since then so maybe things are better. But the decisions taken wrt Workers doesn't inspire a lot of confidence. Even a Google Cloud engineer mentioned that Isolates probably aren't trustworthy enough to run untrusted code side-by-side https://news.ycombinator.com/item?id=18417257
Not that long ago Cloudflare was bitten by a nasty bug where their own parser mixed up HTTP responses from different customers https://bugs.chromium.org/p/project-zero/issues/detail?id=11...
Cloudflare’s response to this incident did not inspire a lot of confidence. What I am trying to say is that I won’t trust their workers implementation unless a competent external security researcher audits it.
Edit: Related discussion https://news.ycombinator.com/item?id=18417257
Your technology page mentions that you provide an mx gateway (presumably for inbound email for home networks that don't usually have a static IP address). You also mention that emails forwarded to the helm server via your gateway are encrypted end-to-end and your gateway cannot read the contents of that email.
I am unable to understand how this happens. TLS is not end-to-end -- since the sending mail server will establish a TLS connection with your gateway it means that you necessarily have to decrypt the incoming email before forwarding it to the helm server.
Can you explain to me how I am wrong here?
If my helm server connects directly with the recipient's email server won't it create problems with SPF validation? Home networks usually don't have a fixed IP address so I am not sure how SPF will work.
https://en.m.wikipedia.org/wiki/Voter-verified_paper_audit_t...