My Best Teaching Is One-on-One


Of course, I team teach and do special lessons, etc.


But my best work in the classroom is after the lesson is over --
going one-on-one,
helping individual students with their assignments.


It's kind of like with computer programs, walking the client through hands-on.
The job isn't really done until the customer is using the program.


Thursday, October 12, 2017

Learning a Foreign Language 外国言語を学ぶには

I had a chat about teaching foreign languages with a potential employer recently. Regretfully, it was not very productive.

Her idea of teaching foreign languages consists of subjecting students to two classes of activity:

Input and output.

At the risk of being rude, this sort of approach treats the student as a machine.

I guess the theory is that you shove a lot of input in, and the human machine (in self defense, maybe?) naturally begins trying to make sense of it. The sense it makes of the information you input would be the first step.

Then you give the human machine a chance to output what it has learned, and you give the machine feedback. The machine supposedly uses the feedback to correct what it has learned.

I'll admit that this is a partially valid view of part of the process. But it's fatally flawed because it is incomplete.

Many humans do not naturally try to make sense of all information they are given. Information that is not deemed important tends to get filtered out. You cannot overcome this filter by sheer charismatic force, and, when you try to do so, you end up creating learning blocks instead of learning.

Teaching is a communication process. It is not one-way, it is two-way.

There are four essential elements of learning a foreign language.

1: Courage, determination, perseverence, and desire;

2: Willingness to make mistakes;

3:  Developing learning strategies;

4: And acquisition of the target language itself.

The first element is obvious not something you can force on a student. If the student sees the teacher mindlessly repeating (for example) a set of flash cards, she might believe there is a reason, or she might believe the teacher is crazy.

Babies have to assume the people around them are doing something meaningful, but they usually don't see people mindlessly rifling through a set of flash cards. They usually see see older children and adults communicating, and the communication they observe is rich with clues.

Students learning a second language are no longer in the do-or-die mode (hopefully). But they still need to see people doing things that make sense in the target language. Mindless repetition is, by definition, not going to be an activity rich in meaning.

There is a theory that assumes immersing the student in a target-language environment. In the extreme implementation, there is no mother tongue help at all. Such help is considered a hindrance to the object of forcing the student to acquire acquisition skills.

It does produce results. Children learn patterned responses, but they don't, except for a few who start out with language acquisition skills, acquire real meaning with the patterns. Without the meaning, the language lessons quickly become little more than a pattern game, like those Simon Says electronic toys: beep-beep-beep gets beep-beep-beep.

But that's in the best case. In the worst case, the students just get discouraged, frustrated, angry, and finally lose whatever motivation they might have had.

What determines whether the students start learning the pattern game or just lose motivation? Nothing more or less than personal chemistry with the teacher.

However, in the language immersion environment, even a little bit of the mother tongue can help untangle this web of de-motivation. And it can also help break through the pattern game.

(Really, any extreme idealism in education can't be good.)

More important than the clues, appropriate use of the mother tongue can be used to encourage the students.

The second element is a purely personal thing, but without it no student is going anywhere very fast.

No one starts with perfect understanding, so everyone makes mistakes. The learning environment has to be somewhat forgiving of mistakes. Not too forgiving, because students need feedback, but somewhat forgiving. Otherwise, mistakes pile up and get in the way of learning. (And when they pile up too much, students get stressed out and maybe even commit suicide.)

Learning strategies, the third element are far more important than teaching strategies. If you ask why, I'll remind you. Learning takes place within the student, not the teacher.

How does a teacher teach learning strategies?

Every teaching strategy you use demonstrates a learning strategy to the student. So you want to use lots of different teaching strategies.

But, even better, letting the students see the teacher in the process of learning something demonstrates learning strategy directly.

What is teaching?

It's one half of a process where information is passed from one person to another. Together with learning, education is simply one form of communication.

Or, rather, communication and education are basically the same thing, with a slightly different emphasis.

The most important teaching strategy and the most important learning strategy are both communication.

When you communicate with the student, you are teaching. When you do not communicate, you are not teaching.

Finally, we get to acquisition.

And if you are paying attention, you will see that I have said something Terrible. Awful. Horrible.

A teacher who does not know the target language, but is willing to learn with the students, can, in fact, lead a clsss in learning the target language.


That pile of 500 flash cards is just another tool, a potentially useful secondary tool.

That list of three thousand key vocabulary words is just another tool, a potentially useful secondary tool.

That book of eighty grammar principles is just another tool, a potentially useful secondary tool.

Tests are just another tool, a potentially useful secondary tool.

One of the primary tools are books in the target language, and a teacher willing to read with the students. Note that I say, "with" more than "to".

Another primary tool is a teacher willing to communicate, even if he or she has to give in and use the student's mother tongue sometimes to do so.

Other useful secondary tools?


Hangman or draw-the-flower, and other spelling games;

Word Bingo and other games that allow students to speak and listen to vocabulary;

AGO and Go Fish and other games that allow students to speak and listen to phrases and sentences;


Role-playing, pair practice, and skits (including English Rakugo) can also help, especially if they are made fun.

Why fun? Because things that are fun have meaning, and things that have no meaning are not fun. It helps bring meaning to lessons, and it is the meaning in the lesson that helps students learn.

Along with the flash cards, writing practice, vocabulary matching, pair practice, etc., use games. They aren't just sugar to help the medicine go down.

Wednesday, October 11, 2017

Basshook Revisited

Okay, so, in spite of a certain rant three years ago, I am on Facebook, now.

It has significantly improved, I think. Or maybe the avalanche that hit me on attempted signup three years ago was due to my path in.

It's still not half what it ought to be. No, it's well less than that. Social networking is thoroughly hamstrung by the underlying profit motivation. We shouldn't have to write all our social activities on a business ledger.

Why did I join Facebook? Lots of people at church are using it. It is a bit more convenient than e-mail for certain kinds of contact.

Also, I'm beginning to suspect that I should quit trying to put someone else between myself and the student and just open up my own English/eikaiwa school. SNS will help with that.

Bonus -- I found the LDS authors Facebook group, LDS Beta Readers. Look them up if you're on FB  and are interested.

Monday, October 9, 2017

New Book -- Grace from the Fall by Mike Mabe

An authors' group I have been participating in recently was invited to review a new book by Mike Mabe called Grace from the Fall. When I saw the title, I half-expected it to be a light young adult or teenage romance about a girl named Grace getting over some social embarrassment. I'm sure that had something to do with the predominance of light teenage/YA romance being written by members of the group. :-)

The title, being an inversion of the over-used title (and philosophical term), "Fall from Grace", interested me, so I read the blurb.

Teenage/YA, yes.

Light? Prison is not expected to be a light topic, although the movie, We Are Not Angels is not extremely deep.

Romance? This book could almost be classed as roman à clef.

But grace is definitely not a young woman in this story.

So now you know how I got interested in the book. I checked my schedule and thought I could squeeze in two reads and a review, so I signed up and got an advanced readers' copy.

Starting into the book was a little rough for me. I kept looking for a girl named Grace, and the writing style is definitely on the younger end of the generation gap. :-/

And the opening scene is a painful one, the start of a foot race. (Track was anything but my forté.) But something in the writing kept my attention, and Mike's description of sports from the point of view of a de-motivated youth is accurate, and not excessively painful.

I didn't put it down until the next morning.

About a week later, it held my attention just as well for the second read. (I did put it down twice, for work and to eat.)

The blurb pretty much tells you what is there -- Mike gives a very readable account of how his fall gave him the opportunity to feel and accept the Lord's grace in his life, which opportunity he had somehow been missing on his way through high school. And he shows us a sympathetic view of the people who find their way into prison without romanticizing prison or crime culture.

This is a book that should enlighten the national discussion on crime, prisons, and recidivism. I recommend it, if you have even a passing interest in the subject, and perhaps the more if you don't.

You can find it on Amazon by searching their books for "Mike Mabe Grace from the Fall", or even searching the web for the same.

I'm told that it will be available through other distributors soon.

Wednesday, July 5, 2017

SNS Cold Calls the Wrong Way (Unsolocited Contact)

Message content on LinkedIn:
Hi! My name is [something cute] and I am 28 and looking for somebody to have a good relationship with. I'd like to know if you are interested?
All sorts of ways, that looks like SPAM. Except, well, borderline. The picture on her personal page, for instance, was demur -- pretty, but not sexy, at least, not selling-it-sexy. And it wasn't exactly a cold call. The request for connection which preceded it was a cold call, in the sense that this was someone I did not know. But the message was preceded by the request, so not entirely cold.

Typically, when I get a request for a connection from someone I don't know, I let it sit for a week. The throw-away accounts from which you get spatter-gun solicitation often disappear within a week, either because the owner runs and hides, or because someone has complained.

Being willing to point out abuse of the networking services is part of your responsibility as a user, of course. I've flagged a few users, and will do so again when I see serious abuse.

Even if the account hasn't disappeared, if you check it out, there are certain tell-tales. There usually isn't much there. What's there looks made up and just bare-minimum. It has usually been just recently registered. There's no depth, so it's hard to tell who or what you're looking at. And, of course, certain kinds of solicitation have that tell-tale appeal to the appetites with pictures that could easily be "borrowed" from who-knows-where.

So, it had been a week yesterday, and I thought I wanted to get rid of the nag. I checked out her personal page and it has reasonable depth. The photos are decent, she has friends who also have pages, and she has a link to an employer who is on LinkedIn and Facebook. She has a nice LinkeIn/Facebook persona to lose if I flag it for abuse.

So I think maybe she's a member of my church, maybe she's a missionary I've forgotten. Or maybe she's interested in the novel that I've been writing but am currently spinning my wheels on, trying to figure out a way to make a profit. Maybe I can connect and let her tell me why she wanted to connect.

So I accepted the invitation to connect yesterday. Today I found the above message waiting for me on LinkedIn messaging -- in French. (Google translate made a hash of it, but did well enough to both English and Japanese that I'm pretty confident of the translation.

So I just went back and looked at her personal page on LinkedIn and, actually, the pages only seem to go back two weeks.

I'm a little disappointed, but this gives me a good basis for a rant on this particular sort of misuse of social networking.

The advantage of social networking sites is that you do have the option of cutting a connection, and of reporting abuse.

But I'm not going to do that yet. Google Translate is not perfect. Maybe this is not a faked persona constructed two weeks ago for the purpose of defrauding lonely old men. A ten percent chance is worth a bit of follow-up. Try to ask if she really meant it the way Google Translate translated it.

But I will, of course, not give the person/people on the other end of this any information they can't find from my public profile -- not even an e-mail address.

(I'll post later on how it turned out, but it should not matter.)

I'm thinking I want to post some pointers on cold calls.

But I realize that I'm not particularly good at them. My sales approaches get ignored. If I try to do cold calls with my résumé, out looking for work, I never make it past the first secretary in HR. My mailed résumés often don't even get acknowledged. (Yes, I've sought professional help with this. It doesn't seem to make any difference.)

The only specific advice I can offer seems to be negative: Don't do it this way.

If you like a blog post, and want to actually establish a conversational relationship with the person who posted it, responding on the blog itself is a good start if comments are enabled. If you make contact via e-mail or SNS, make sure you mention that blog post early, preferably with the URL.

And I want to suggest to the spatter-gun solicitors with no real product that they get a real, legitimate product. Abstract product is okay. Just don't use deception to get money without giving a product in return. Getting money that way only leaves you desperate again for money tomorrow or next week.

And be patient. Legitimate relationships, business, friendship, or otherwise, take time to establish.

Wednesday, June 28, 2017

Your Memory Map is No Longer Trivia

You think you don't really care about how applications and such are laid out in your computer's memory, but you should.

I have worked up a little programming exercise to help you examine your computer's memory map, in my programming is fun blog (which I really wish I had more time for). It explains a little about what memory layout means. If you aren't familiar with the problem, or just want to look at a little trivial bit of C language code that can show something about your computer's layout, take a look at that.


gallier2 points out something I tend to forget about: pmap will give you much more information than the little (emphasis on little) program I wrote, posted and linked above -- stkreveal.c .
man pmap
It's a useful tool. And I think it's in cygwin, as well. If you don't understand what it's telling you, reading about and playing with that little stkreveal.c program might help.

(I need to spend more time working with the low level OS tools.)


You may recall some horror stories about stack smashing and stack crashing in the distant past -- maybe even within the last ten years. You may remember that it describes a technique for someone who wants to access the stuff on your computer without your permission to do so. You may remember feeling relieved when the various vendors said the problems were solved (for some domain of the problems).

Recently, one of the companies that is currently investigating computer security decided to revisit the problem. This time, the easy crashes and smashes are quite well protected, but they found some new ways to get around the protections.

I got the news on the openbsd misc user list today. And I found the report here.

(Together with the Kaby Lake and Skylake problems, I got motivated to write this rant and the programming rant.)

At first, I was wondering why they were misspelling "crash". But they were just having a little fun, and pointing out that the existing protections are not sufficient. (If you wonder why they can joke about something like this, you have to understand that waiting all day for a program to break something can get a little boring.)

If the waiting all day sounds like the problem isn't too bad, don't worry, some of what they found works in less than a minute.

Okay. Worry a little.

Most of the vendors have been implementing mitigation techniques, and they aren't hard. The guard pages don't consume memory, whether 4K or 1M, for one. They only consume mapping table entries (which Intel has been delinquent in giving us enough of).

Those techniques aren't perfect, either, but they help. Your average $Kr!p+ k!DDi35 may not have enough patience to use them, so you probably only have to worry about government security organizations and organized crime. (Organized crime doesn't get the tech until a little after the government, usually, anyway.)

Part of my purpose in this rant is to tell anyone who might be wondering, why I don't have a lot of positive thoughts for either Intel or Microsoft.

This problem has been known for a long time. Fixing it is not hard. I'll explain that in another rant, maybe today, maybe later. But it means the processors you make can't be quite as fast. And it means the OS and applications you make can't have quite as many features.

And that means there can be something besides price and apparent ubiquity to differentiate the competition's product from yours. It gives the competition more room to compete with you on their terms instead of yours.

(It would mean that Intel wouldn't be able to just buy up all the best semiconductor engineers, to keep them off of the competitions' payroll. And it would mean that Microsoft's sales department couldn't run their engineering.) 

(And it would mean you couldn't just smooth talk your customers and invite them out for a game of golf and a visit to the nearest mosh pit to seal your deal. You'd have to compete on meaningful functionality.)

If you've already read my Memory Layout rant, here's what the "Stack Clash" business is, in the overview. (If you haven't and are lost, go read that.) First, an early 32-bit addressing CPU might have memory laid out something like this:

  stack (dynamic variables, stack frames, return pointers)
0x000FFxxx ← SP
  heap (malloc()ed variables, etc.)
  statically allocated variables
  application code
  operating system code, variables, etc.


To make this really clear, I am intending, by heap, to include everything allocated by mmap() and brk() and such, as well.


That's way over-simplified, but note that the same problem remains. And faster processors can eat up memory faster, so the extra memory doesn't really help protect things.

A slightly more modern, 32-bit map might look something like this:

  stack (dynamic variables, stack frames, return pointers)
0x0FFxxxxx ← SP
  guard page (Access to this page triggers OS responses.)
  heap (malloc()ed variables, etc.)
  statically allocated variables
  application code
  operating system code, variables, etc.

This is also still way over-simplified, but the gaps are mostly mapped without physical memory, and so is much of the application and OS space. Accessing those gap spaces allows the OS to add more memory in some cases and terminate renegade processes in others. If the guard page is accessed, the OS can be
pretty sure the application is out of control.

This is much improved, and it is the way many 32-bit OSses were mapped ten years ago. But it can be a little tight, motivating us to use a small guard page, to avoid wasting address space.
The small guard page is an important part of the problems the Stack Clash uncovered. If a program has large enough local variables, particularly, larger than the guard page, it can sometimes be caused to allocate one of those large variables without hitting the guard page.

And there are similar problems that opening up the memory map makes a little easier to deal with. So, we'd prefer something like this:

  stack (dynamic variables, stack frames, return pointers)
0xFxxxxxxx ← SP
  guard page (Access to this page triggers OS responses.)
  heap (malloc()ed variables, etc.)
  statically allocated variables
  application code
  operating system code, variables, etc.

You can see how this gives lots more room. In particular, with this kind of map, we can usually use 1M guard pages, which are much harder to force a program to miss.

Taking this to 64-bit CPUs, you might think the addressing ranges pretty nearly completely mitigate the problems, but let's see what Intel, the motherboard vendors, and the OS vendors have given us. It looks something like this:

  stack (dynamic variables, stack frames, return pointers)
0x00007Fxxxxxxxxxx ← SP
  guard page (Access to this page triggers OS responses.)
  heap (malloc()ed variables, etc.)
  statically allocated variables
  application code
  operating system code, variables, etc.

That's roomy, but what we want, of course, is more like this:

  stack (dynamic variables, stack frames, return pointers)
0x7FFFxxxxxxxxxxxx ← SP
  guard page (Access to this page triggers OS responses.)
  heap (malloc()ed variables, etc.)
  statically allocated variables
  application code
  operating system code, variables, etc.

You want to get each major block in memory as far away from every other as we can. But Intel says that practical considerations give them an excuse to scrimp on decoding and claim higher processor speeds.

(Higher processor speeds than their competitors so they can maintain their stranglehold on certain sectors of the CPU market, and use that stranglehold to keep pushing relentlessly at the rest of the semiconductor market.)

I'm not explaining how Microsoft fits into this, but a little thought should produce the obvious.


We in the industry have been far too long designing to the black hat skills of yesterday. 1M guard pages are better than 4K guard pages, but they really aren't enough, either. (I will refrain from explaining why here, since I am not inclined to educate the black-hats. People who figure these things out on their own tend to behave more responsibly with the knowledge.)


Hopefully, I can I have now posted an outline of a different sort of solution one of these days, and a discussion of how to go one step further in hardware, to really protect the return addresses.

(OT, but I'm getting a little tired of the way Google's javascript gadgetry keeps mishandling characters used in XML tags when I try to edit things like the above as HTML. If it gets scrambled, that's probably why. And I do need to start using using my off-line tools and quit using their on-line tools, to just avoid the problems altogether. Or maybe Google didn't want me talking about government security organizations, since that's the paragraph that seemed to beak the round-trip editing.)

Monday, May 22, 2017

journal 20170522

So I think I'll start posting parts of my work journal.

I'm still spinning my wheels.

My last contract ended in March.

In complete rejection of logic and reason, I have not been burning myself out to find a new job.

I have a series of novels I want to write.

Nobody but my oldest sister is reading them.

After the contract ended, I've been stuck on a little side-tour.

I needed to calculate the calendar of the world where the first several stories take place.

Then I got really interested in the puzzle of adding double integer divide to the base wordset of the programming language Forth.

Last week, I pretty much proved to myself that there are no easy, fast, deterministic methods for division, the way there are with multiplication.

Not a mathematical proof, just finding a difficult problem that no one else seems to have solved.

We humans intuitively use estimates when we divide large numbers.

We have the multiplication tables memorized, and we use those tables in division.

When doing this in computers, those tables can become larger than the entire memory of the old 8-bit processors.

The Forth that needs the double length divide is an 8-bit CPU implementation.

Fortunately, the size of the table depends on the numeric base you operate in.

The table for one digit of decimal math is not really big, only 100 elements:


But we are not talking about one digit of decimal math.

The smallest table we can do without using bit shifts is a table for one column of base 256 math.

ビットシフト演算なしで一番小さい表はなんと 256 進法の一桁の表です。

That means a table 256 wide and 256 deep. That's 65,536 16-bit integers.
つまり、 256 桁の 256 行の表です。 65,536個の 16 ビットの整数です。

I'm not going to reproduce that here, because I'm pretty sure it would give your browser fits, not to mention what it might do to blogspot's template engine.


(Blogspot might accuse me of trying to DOS them, and you might accuse my of DOSsing you.)

Now the problem is the shifts. Left shifts are just doubling, so they are pretty cheap. It's just an addition.

Unless you have actual bit shifts, shifting to the right is expensive, requiring a division.

It's a relatively cheap single-wide division, so it's not a chicken-and-egg problem, but even single-wide divisions take a long time on old microprocessors.

Addition on old microprocessors takes maybe ten microseconds. Division takes easily 200 times that.

It's possible to use scaling to reduce the amount of math required without the tables, but scaling requires shifting as well.

Binary division is different. This is all there is to the table:


And binary division is just shifting, subtracting, and counting.

It's slow, but it's straightforward.

So, if I have to use shifts anyway, I may as well go down to the machine level and implement the division in assembler anyway.


I have the program running, and it produces monthly calendars for the planet that I think are accurate. The source can be found, complete with the code for dividing double integers, in my Xhilr Calendar workspace at OSDN Japan.
暦作成のプログラムは稼働できます。その惑星の正確性在るとボクが思っている月毎のカレンダーが作成できます。倍幅割り算を含めたソースコードをボクの OSDN Japan 上の Xhilr Calendar 作業部屋に置いています。


This is not the way a sane person spends his time when he needs to be finding a new job, you know.

Last Sunday, I went to the special stake conference in Kõbe and listened to Elder Oaks and other Church leaders.

I'm feeling much less down.

Monday, May 15, 2017

Do Not Pay the Modern Danegeld! -- Ransomware

Yesterday, I read in the paper how ransomware has been spreading.

It would be easy to waste electrons castigating Microsoft for leading the establishment of impossible-to-secure software as industry standards.

(The words "unsafe at any speed" make me wonder why Nader has been mostly silent about the current computer industry.)

It is true that software, including operating systems, is not exempt from the mathematical principle that absolute security is an internally inconsistent concept.

But the habit of the industry has been to rely on lack of education rather than actual prevention.

This combined with excessive competition for the market has led to unsafe practices built on unsafe features built on unsafe practices.

We all know that our information devices are unsafe -- impossible to secure. (Or, if you do not, you have been deliberately closing you eyes. Perhaps you think there is nothing to do about it.)

So, now someone you know is looking at a message on his or her screen:

Pay up or lose your precious data!
You seriously can't be thinking
$300 is cheaper than losing my mail archives and address book!
Let me put the real costs in front of you:

Every dollar you give in ransom is the price of one bomb or landmine, small enough to hide, large enough to kill and maim humans and animals, large enough to destroy or disable cars, trucks, roads, communication lines, etc.

Every bitcoin paid in ransom is 1,700 such bombs.

And if you pay it now, you will be faced with paying it again.

What should we do?

Step back, take a deep breath, let common sense flood back into your brain.

  • Do you have backups?

If not, now is the time to start planning.

  • Can you reconstruct the data?

Re-constructing the data may take time, but if you can't reconstruct your data, it was never yous in the first place.

("Big Data" is a comfortable illusion with some substantial features, but you really should be honest with yourself about that. Money doesn't really grow on data trees, whether binary, b-star or otherwise.)

  • Okay, you have partial backups -- USBs, dropboxes, cloud services, etc. 
  • And you can reconstruct the most important data, if you are willing to take the time. 

So, no, the data that has been locked away from you is not worth continuing to arm the enemy.

  • First step, shut that computer off. 

If you have reason to believe that the ransomware will try to delete data on shutdown or some such stupidity, pull the plug and the batteries.

Your local geek may be worried about data loss on shutdown, but the converse is also a problem. Hiding is easy, but encryption takes time.

Remove all hard disks, SDs, and USB storage devices that were attached when the malware showed up, and collect all external storage that has been attached to the infected device in the past week, at least.

Learn something about security. Do not depend on books with names like "Security for Dummies." Dummies are soon chumps, and that's how you got in this mess.

Yes, I should write a book. Somebody front me the money. Oh, well, that's not happening very soon.

Two of my blogs, free is not free, and defining computers have some useful information, but some of it is old, and both mix rants, daydreams, and parable with practical advice.

So use your own brain. Here's a start:
  1. Think about what secrets are. 
  2. Think about what computer data is.
  3. Think about walls and locks
  4. Think about protocol.
Think about what the limits of the above are without computers. Then convince yourself that computers are not magic. Fast and re-writable, but not magic.

I'll list a few really relevant rants:

Back to practical steps:

  • Re-flash the BIOS of the infected device. 

If you don't do that, you're likely to get re-infected. BIOS attacks are becoming commonplace, and the ransomware attacks are at that level.

(And, yes, there are indeed huge problems in the new BIOSses. Reflash or buy new, but buying new is a problem, too.)

  • Install new boot and other internal media (new hard disk or SD for boot and data) and install a new, safer OS.

I'd recommend a Linux OS such as Debian, Ubuntu, or Red Hat Linux, but, really, the marketplace has been infecting those with unsafe applications, practices, and features for the last fifteen years.

Eventually, I want to recommend installing a Linux or BSD OS and installing MSWindows in a VM on top of that, but that is not yet ready for prime time, and Microsoft and Intel seem to think they have financial incentives in working behind the scenes to make that not happen.

If you have to use a Microsoft OS, just don't keep important data on it, especially not without backup.

  • Make a plan about where to store your data.

As much as it galls me to say so, yes, I'm suggesting NAS and cloud if you have any really valuable data.

At bare minimum, keep copies on USB drives that you properly unmount before removing. (Click the "remove" button and wait until the OS says it's okay.) And do not keep the USB drive inserted in the computer while you work.

Do not keep any valuable data on your workstation. (I say, but I can't afford to do otherwise right now. I'll have to take my own advice and collect my data onto an external device, as soon as I get some résumés sent out. But I'm using an OS I'm fairly confident I can still trust.)

  • Take a little time to review what you think you know about computers on a regular basis. Learn an alternative OS.
  • Take time to understand your data, what you have, and what it's worth.
Now that we have that out of the way, now is the time to think about recovering that locked-up data.

  • First, mount the media device (hard disk, SD, USB) on a known-safe machine. 
  • Then look around and see what was actually encrypted and what was just moved somewhere.
  • Then go look for tools for un-erasing data. The attackers may not have encrypted the partitions, and probably has not tried to find deleted files to encrypt. So you will likely be able to recover up until the last save, even if the encryption really is unbreakable.
  • Finally, if you still have data that is highly valuable and not recovered, now you know how much you will be willing to pay a legitimate professional to try to get it back by brute-forcing the encryption keys.
That last list is the one you wanted me to tell you first. But that would not be helping you to be secure the next time, and the next time is already waiting for you.