[EU/SEPA Only] If you have signed a B2B SEPA Direct Debit (SDD), it's enough to revoke it on your banking portal as you have mentioned. Your bank is required for a signed Mandate to be able to debit your account. If you have been debited already for a B2B SDD, you only have 3 inter-banking business days to try to Reject the payment (if your bank offers that as a service), afterwards the bank that has issued the SDD is not legally bounded to return the money.
If it's a Core SEPA Direct Debit, there is not the concept of a "signed mandate" but according to the rulebook [1] you have up to 13 months [2] to ask for a Return.
[_sigh_] I've spend so much team reading those rulebooks
[2] "If the request for a Refund concerns an Unauthorised Transaction, a Debtor must present its claim to the Debtor PSP within 13 months of the debit date. [...]"
Shameless plug; I've been playing with a [Redis Server implementation in Go](https://github.com/jan-carreras/ddia) for the past weeks. Mainly as a way to try out things explained in Designing Data-Intensive Applications book (favourite of mine!). Those are the [commands implemented](https://github.com/jan-carreras/ddia/blob/master/commands.md), + TTL + AoF files (for state replication) + config file, ... The "challenge" was to do it without any external dependency other than go stdlib.
> I actually build minimal Redis clones in every new language or runtime, or when I want to explore threading models.
100% agree with your advice; I'll definitively try to implement other parts of the Redis service in Go (eg: pub/sub, replication, clustering...) and probably repeat the same exercise when learning any new language.
Yeah, thought the same. The AML team on a bank cannot disclose that the account is being investigated by the regulator, nor give any information to the client about it.
Of course, if the bank wished to do so, they could give information or unblock the funds. But the fines that the regulator can impose to the bank are disproportionate (hundreds of thousands, per individual case) to "convince" the bank to comply.
Thus, is not "the bank" who is doing that to you, it's the regulator, and the agreement between the bank and them. And this "agreement" is a requirement in order for the regulator to give a banking license, so...
Let's be clear, the bank is not gaining anything out of this, quite the opposite: they are at risk of bad reputation, having an angry customer at their offices or calling daily, etc...
It's a very frustrating situation, tho. I do understand that.
For me the use case is: someone leaves a comment that's ambiguous, someone asks for clarification, some people respond _what they think that original commenter meant_, finally originally commenter solves the doubt.
I find myself Control+F the name of the original commenter to see if he/she has replied, because I'm interested in _that_ response — not so much of the interpretation of others.
Wanted to PM you but no contact info, so I'll do it thru here.
> Finding solid, dependable people with the right skills and attitude is really, really hard.
1. What are the soft skills of the candidates that you most value?
2. After 6 months, what the most important aspect that you value to decide if it was a good/great hire?
3. Offtopic: Do you have an all time favourite book for growth/self improvement you could recommend?
The book about him[1] explains how he is a workaholic . Not just by the worked hours, but the intensity of those, context switching between projects and attention to detail, pressure teams, etc...
I understand your point about "waste of his position" and that he could have a more balanced life, but as the books depicts him that's not the case. Nor it was when he was at PayPal or Zip2.
> When someone comes at your approach wielding a slogan, be skeptical.
I do agree. Although the point of the article is to _lean_ more on "boring technology" side of, and paying extra effort when considering adopting newest flashy things.
Having read the article 3-4 time in the last years, I don't think they say "don't use new things", just "not too many new things at the same time"
Perhaps the title should be “err on the side of boring technologies”, although I don’t even agree with that. The right technologies for a project are the ones you deem to be right, given appropriate consideration of many factors. Your project may really need to use all beta release software, cause maybe it just does.
Let's say you've given it the proper consideration, and it's clear beyond the smell of subjectivity that it needs to be flashy stuff, go for it. The point is that this is often not the case, and the argument is to go with boring then.
I would agree that we're talking about the same thing, really:
> The right technologies for a project are the ones you deem to be right, given appropriate consideration of many factors
It's _usually_ difficult to take into consideration all the factors of a new flashy thing. The unknown unknowns. Thus _maybe_ choosing a trendy set of technologies might indicate that the exercise of balance and consideration you were commenting and that I do agree with 100%, has not been as honest as possible.
Improvement suggestion: While reading the README, the JSON library comparison [1] it's confusing, at least to me. It uses symbols like: ○, and △ which are not obvious. I would rather use "yes/no" or the classic check/x (unicode chars, HN does not support them here) if you want to use symbols. I don't know what "△" even means, so I cannot suggest an alternative.
Another suggestion in the chart: it isn't obvious which line is about your project because it doesnt list the `goccy/` part. I would add that and move it to the top, out it and the standard in bold.
I strongly suggest you the Loop Habit Tracker [1][2]. Simple yet powerful app. You configure your habits and associate a frequency, and once done they disappear from the list. You can set up reminders/alarms as well.
The only "tip" I would suggest to you is to open the app once a day. For that, I created a daily habit of "checking my habits". A little bit meta, but it holds myself accountable.
Some of my tracked habits: calling mom/grandma, reading, use Anki, gratitude journal, exercice, drink 1.5L or water a day, meditate, breathing exercices, no screen time after 20:00, etc.
Of course, not meant to disencourage you from doing your own app, just to show how I scratch my very same itch. May the code be with you ;)
How Golang[1] implements monotonic clocks — basically it retrieves always both wall and monotonic clocks on "time.Now()" and when doing operations of subtraction it uses the monotonic. When printing, it uses the wall time. Pretty neat. Details on the proposal by Russ Cox [2].
That’s a hard question regardless of programming language. One commonly referenced YouTube video about time that explains why this is hard: https://youtu.be/-5wpm-gesOY
A reasonable first approximation of a solution would be to just check every second (or minute, or hour, depending on requirements) whether the current system time is later than the scheduled time for any pending events. Then you probably want to make sure events are marked as completed so they don’t fire again if the clock moves backwards.
Trying to predict how many seconds to sleep between now and 3pm on Saturday is a difficult task, but you can probably use a time library to do that if it’s important enough... but what happens when the government suddenly declares a sudden change to the time zone offset between now and then? The predictive solution would wake up at the wrong time.
No, you say "sleep until 3pm on saturday" you don't predict anything. The OS computes an exact value to wake up in when you arm. If that clock then jumps forwards or backwards or does anything weird you then recompute the expiry timeout for that timer. You can't do this in app-space but AFAIK all OSes provide a facility for you to do so.
Well, the parameter of a Timer is of type Duration:
A Duration represents the elapsed time between two instants as an int64 nanosecond count. The representation limits the largest representable duration to approximately 290 years.
Which is not really good because we have to calculate the time between now() and Saturday. If "wall time" changes, the scheduler will not be triggered when expected.
In that case I would not rely on Timer to use it in a cron-like fashion, or trigger a Ticker every second, check the _current_ wall time, and decide if anything needs to be done.
You can read more about Timers, Tickers and Sleeps in this (pretty interesting) article[1]
Operating systems spend a lot of time designing APIs for you to deal with time correctly. The approach you've described is a limitation in Go, not inherent in general software development.
If it's a Core SEPA Direct Debit, there is not the concept of a "signed mandate" but according to the rulebook [1] you have up to 13 months [2] to ask for a Return.
[_sigh_] I've spend so much team reading those rulebooks
[1] https://www.europeanpaymentscouncil.eu/what-we-do/sepa-payme...
[2] "If the request for a Refund concerns an Unauthorised Transaction, a Debtor must present its claim to the Debtor PSP within 13 months of the debit date. [...]"