pfft - https://www.w3.org/Provider/Style/URI.html
sure, but the vast majority of URIs are not cool ones
Programming book authors: put all the code in the book
71–80 of 83 posts
Re: Programming book authors: put all the code in the book
#72Just glue an envelope with a CD to the backcover, this is what people were doing before your fancy internets became a thing. But really, if you a writing a book on a modern language, and your code has external dependencies, chances are it will not build 5 years forward, even if there are no URLs directly in the book.
> Just glue an envelope with a CD to the backcover
Those CDs have a way of disappearing. My local library used to have a lot of tech books that were missing the accompanying CDs.
Re: Programming book authors: put all the code in the book
#73So if you write a book about Python, you should include the full source code to Python as well, right? If you write a book about Java, the full source code to the JDK, and so on. Because if the readers have to download and install that by themselves, the book would not be self contained anymore, URLs may break, etc etc.
Ah, no, programming language runtimes are Ok, no need to include them. But then if you write a book about React, or MySQL, or... well, you get the point.
Re: Programming book authors: put all the code in the book
#74Earlier quoted context omitted.
> You should be able to get a few MB on a page easily A few hundred Kb, maybe, but a few MB seem unlikely. If I take the best case scenario (no optical aberration, perfect sensor...), my phone has a 48MP camera. We cannot have 48M * 3 colors as those 48MP are after Bayer matrix handling. We also cannot have more than one bit of information per pixel, due to printing often not having "real" greyscale but some kind of…
I think you confused printed pixels with camera pixels along the way.
I explicitly talked about the best case scenario, which would have been "one camera pixel is able to retrieve precisely the information of one printed pixel (or several printed pixels that act as one)"
From there, I simply listed sources of error that would make it worse and words. The only place I could see conflation occurring is when I wrote about "sub 0.1mm" which indeed refers to the printed thing, and correspond roughly to the tolerance that would be needed to achieve millions of "printable" pixels, but even if it's about the printed pixels, it still limits the amount of information that would be stored.
Would you mind indicating where there seem to be confusion according to you? Re-reading it quickly, the comment seems consistent and indicates that both the camera pixels AND the printed pixels would cause issue.
Re: Programming book authors: put all the code in the book
#75Earlier quoted context omitted.
I think you confused printed pixels with camera pixels along the way.
I explicitly talked about the best case scenario, which would have been "one camera pixel is able to retrieve precisely the information of one printed pixel (or several printed pixels that act as one)" From there, I simply listed sources of error that would make it worse and words. The only place I could see conflation occurring is when I wrote about "sub 0.1mm" which indeed refers to the printed thing, and correspon…
I don’t know, still seems feasible. High quality full page images can be printed at ~2500x3500 pixels per page [1] (random print shop from the internet, but representative AFAICS), and that’s just what printers recommend for human readable images, they can produce images easily to 1200 DPI.
In another example, take the Machine Identification Codes (MIC) tracing dots that basic home printers can produce [2], (I bet the publishing industry could do much better to produce a high density grid.)
These dots have a stated diameter of 0.1 mm, and on an 8”x10” area one could get a grid of 80x25.4x25.4x(1/0.1mm)x(1/0.1mm)= ~5.1M dots.(wikipedia claims larger spacing, but that must be the protocol, printing itself allows for highly precise positioning) And that’s just for one color. Use CMYK (you could imagine a sub-project to design a 8bit color based dot scheme) and compression, and even with ECC losses I can see a few MB of encoded source per page being possible. And writing that decoder would be a great exercise!
[1]: https://www.docucopies.com/image-resolution/
[2]: https://en.m.wikipedia.org/wiki/Machine_Identification_Code
Re: Programming book authors: put all the code in the book
#76Bring back the 90's antipattern of making the book so thick you use it as a monitor stand.
I got this [1] a few years ago deluding myself into believing that I'll learn a bit from it everyday. Alas, the only way it's useful to me on a daily basis now is as a monitor stand. I remain cautiously hopeful that I'll begin pecking at it someday.
[1] https://www.amazon.com/Princeton-Companion-Mathematics-Timot...
Re: Programming book authors: put all the code in the book
#77Earlier quoted context omitted.
> That seems particularly appropriate for posting code examples. Github is a proprietary, closed-source service that makes no promises about keeping things for a long time. And even if they do, at the time convenient for them, they'll send out an email titled "We are changing our ToS", and users will just accept it. Doing infra work for researches I encounter so much dead and dysfunctional content on Github, it's a m…
> Github is a proprietary, closed-source service that makes no promises ... Good point. > Python code has an average shelf life of four years. Wouldn't that also be a problem for examples in print?
How much are you going to print?
If you print "just the program" (i.e. no dependencies), it will spoil very quickly.
If you print both the program and dependencies, it will live a little longer.
If you print dependencies and the source of the interpreter, it will live even longer.
If you print the interpreter and its dependencies -- even longer.
As you can see, the general problem with languages like Python is extreme reliance on external components. Essentially, Python programmers don't write whole programs, they add a polish on an automobile manufactured by someone else, and then present it as their work... Unsurprisingly, it's hard to ensure one's car's longevity if all they can control is the amount of polish they apply to it.
Re: Programming book authors: put all the code in the book
#78Earlier quoted context omitted.
No? It's in the imperative voice, it wouldn't make sense to read "do this" as a description of an antipattern.
Why not? A TL;DR is a summation of the article. The title tells what the article's about. So just reading the title and the tl;dr would leave one with no actual idea of the antipattern. What if the article was about something for which the imperative voice was an accurate description?
Describing something in the imperative voice doesn't make sense.
Why would you ever say "TL;DR perform this action" instead of "TL;DR performing this action", when trying to describe something that people should not do?
Re: Programming book authors: put all the code in the book
#79Earlier quoted context omitted.
"Teach yourself J2EE in 21 days, 2nd edition" remains marvellous for this :-D
My copy of 'Programming Perl' is the thickest book on my shelves, narrowly beating out 'The Peloponnesian War' (though the latter is taller, so it's hard to say which is the longer read).
Inside SQL Server 2008 T-SQL Programming is somewhat thicker. In fact, it is about the size of Programming Perl and Modern Perl together--though I must add that Programming Perl lost its front cover a while ago.
Re: Programming book authors: put all the code in the book
#80pfft - https://www.w3.org/Provider/Style/URI.html
sure, but the vast majority of URIs are not cool ones
I agree in principle. My (unstated) point though is that when you have a second order solution to a second order problem, it is often worth considering moving up the stack to work out why that is.