Send an ebook to your kindle

Problem: I have an ebook but I didn’t get it from Amazon, so it isn’t sent to my kindle directly. What can I do?

Solution: Send it to your kindle using your kindle email address.

Example –

1. Get a book from Gutenberg.com and save it locally:

GutenbergDownload

2. Send this file as an attachment to the email address of your kindle. You can find this on your Amazon account’s, Your Content and Devices section:

KindleEmailAddress - NEW

3. Sync your kindle and enjoy

Confusing UI

20190325_155353

From a hotel I stayed at a couple weeks ago. On its left is a window with a shade. On its right is another window with a shade.

If you want to raise the right set (shade and window), how would you do it?
If you want to lower the shades on the left, but only halfway, how would you do that?
Should the stopping of raising or lowering require a separate button push?

Levels of knowing a programming language

1) You can read and understand what the code does

2) You can modify existing code to do something different

3) You can write code from scratch that does what you want

4) You can fully utilize the language syntax and its libraries

5) You write programs with the language for things people don’t even imagine and use it in ways people barely believe

slashdot 

Anti-patterns

An anti-pattern is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive. The term, coined in 1995 by Andrew Koenig, was inspired by a book, Design Patterns, which highlights a number of design patterns in software development that its authors considered to be highly reliable and effective.

Stovepipe or Silos: An organizational structure of isolated or semi-isolated teams, in which too many communications take place up and down the hierarchy, rather than directly with other teams across the organization

Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules

God object: Concentrating too many functions in a single part of the design (class)

Silver bullet: Assuming that a favorite technical solution can solve a larger process or problem

https://en.wikipedia.org/wiki/Anti-pattern

How to write unmaintainable code

In the interests of creating employment opportunities in the Java programming field, I am passing on these tips from the masters on how to write code that is so difficult to maintain, that the people who come after you will take years to make even the simplest changes. Further, if you follow all these rules religiously, you will even guarantee yourself a lifetime of employment, since no one but you has a hope in hell of maintaining the code. Then again, if you followed all these rules religiously, even you wouldn’t be able to maintain the code!

To foil the maintenance programmer, you have to understand how he thinks. He has your giant program. He has no time to read it all, much less understand it. He wants to rapidly find the place to make his change, make it and get out and have no unexpected side effects from the change.

He views your code through a toilet paper tube. He can only see a tiny piece of your program at a time. You want to make sure he can never get at the big picture from doing that. You want to make it as hard as possible for him to find the code he is looking for. But even more important, you want to make it as awkward as possible for him to safely ignore anything.

Programmers are lulled into complacency by conventions. But every once in a while, by subtly violating convention, you force him to read every line of your code with a magnifying glass.

You might get the idea that every language feature makes code unmaintainable — not so, only if properly misused.

Roedy Green, Canadian Mind Products
@ github

AOL Late 90’s

January 1999
AOL 1999.PNG
via the wayback machine
https://web.archive.org/web/19990125084628/http://aol.com/

The late ’90s, according to Schober, was when chat rooms hit their peak. Just how powerful was America Online during this time? Reggie Fairchild, product manager for AOL 4.0, shared this little story on Quora:
“When we launched AOL 4.0 in 1998, AOL used ALL of the world-wide CD production for several weeks. Think of that. Not a single music CD or Microsoft CD was produced during those weeks.”
It worked. People signed up in droves.

via CNN

Lessons for creating good open source software, Eric Raymond

  1. Every good work of software starts by scratching a developer’s personal itch.
  2. Good programmers know what to write. Great ones know what to rewrite (and reuse).
  3. Plan to throw one [version] away; you will, anyhow. (Copied from Frederick Brooks’ The Mythical Man-Month)
  4. If you have the right attitude, interesting problems will find you.
  5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
  6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
  7. Release early. Release often. And listen to your customers.
  8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
  9. Smart data structures and dumb code works a lot better than the other way around.
  10. If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource.
  11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
  12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
  13. Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away. (Attributed to Antoine de Saint-Exupéry)
  14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
  15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to!
  16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
  17. A security system is only as secure as its secret. Beware of pseudo-secrets.
  18. To solve an interesting problem, start by finding a problem that is interesting to you.
  19. Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.
  20. When the next generation inevitably stumbles for the second time around on the first contention, doff cap and take heed;

* Eric Raymond, via wikipedia

Toyota’s Six Rules for the application of kanban

Toyota has formulated six rules for the application of kanban

  1. Each process issues requests (kanban) to its suppliers as it consumes its supplies.
  2. Each process produces according to the quantity and sequence of incoming requests.
  3. No items are made or transported without a request.
  4. The request associated with an item is always attached to it.
  5. Processes must not send out defective items, to ensure that finished products will be defect-free.
  6. Limiting the number of pending requests makes the process more sensitive and reveals inefficiencies.

via wikipedia
https://en.wikipedia.org/wiki/Kanban

Health care workers and computers, Atul Gawande on.

Why Doctors Hate Their Computers

More than ninety per cent of American hospitals have been computerized during the past decade, and more than half of Americans have their health information in the Epic system. Seventy thousand employees of Partners HealthCare—spread across twelve hospitals and hundreds of clinics in New England—were going to have to adopt the new software. I was in the first wave of implementation, along with eighteen thousand other doctors, nurses, pharmacists, lab techs, administrators, and the like.

https://www.newyorker.com/magazine/2018/11/12/why-doctors-hate-their-computersc

Clojure Hello World

user=> (println “Hello World!”)
Hello World!
nil
user=> exit
Bye for now!

check out ->

Leiningen is the easiest way to use Clojure. With a focus on project automation and declarative configuration, it gets out of your way and lets you focus on your code.

https://leiningen.org/

Build Your Functional Skills One Idea at a Time, by Russ Olsen
https://pragprog.com/book/roclojure/getting-clojure