It's totally possible (and a relatively frequent occurrence) to have pdfs where the order of characters in the code has no relationship at all to how those same characters are laid out visually on the page. Anything marginally more complex than a series of paragraphs with no formatting at all basically requires you to render out the whole pdf and figure out the order that you are actually supposed to read the characters in.
Yup. For instance, Word's PDF output, has an absolutely positioned textbox for every word (and sometimes sub-word). This is for kerning purposes. If you want your original text back, you're going to need some OCR-like preprocessing and heuristics to guess what textboxes belong to the same line. If you have multiple columns, good luck distinguishing them from accidental rivers.
It's not impossible, but I wouldn't know immediately what tools get this most right. And it's always a lossy operation going back and forth.
> the whole "Earth is the centre of Universe" thing that held back modern thinking
This says much more about how we dismiss ancient civilizations as inferior than it does about ancient civilizations themselves.
The fact is, the geocentric model was an excellent one, able to explain all observations at the time in a sensible and straightforward way. Admittedly, more data helped to develop the heliocentric model, but there were valid scientific criticisms against that model at the time. In particular, it took Kepler to provide truly sensible and strong arguments in favor of heliocentrism.
The geocentric model is so good that even today it is often the sensible model to use when thinking about some astronomical problems. I hate to hear it being dismissed as 'wrong' - because from a physical perspective the two are simply geometrical transformations of one another, they are both 'right'. It's simply that one of them is simpler than the other for most problems.
But most of all, I hate hearing people say it 'held back thinking', because I assure you that the people doing the thinking back then were just as capable of doing good, logical, rational thinking as we are today, and didn't need anyone to claim they were too stupid to think critically for themselves about the scientific understanding of the time.
> because from a physical perspective the two are simply geometrical transformations of one another
Not really, at least if you want to keep simplicity of Newton's laws which are formulated for inertial reference frames. The reference frame in the heliocentric model is inertial, while in the geocentric one it is not.
Notice that 17 days is basically what is needed to add the issue to the next sprint, complete its development along with everything else for that sprint, and deploy to a live site. To me that sounds fair.
I would argue that the surveillance isn't in how the data is used, but rather in the fact that NYC has that data at all.
Limits on acceptable data collection are more straightforward, enforceable, and fair than limits on acceptable data analysis. What would you say if a human had reached the same conclusion as Palantir by analyzing the same data?
> Limits on acceptable data collection are more straightforward, enforceable, and fair than limits on acceptable data analysis.
I strongly disagree. In this electronic age, it is unreasonable to to expect companies and agencies not to store data electronically. Isolated, these data points are not illegal - the USPS knows your address, the IRS knows where you work, the DOT knows your license plate - these are all necessary for these agencies to do their jobs. Private companies know stuff too - your phone company knows about calls you make, your ISP knows about sites you visit, your bank knows about purchases you make. Some of these can be forgotten, some are necessary to do business.
The problem comes when someone cross-references innocent data to a level that results in an invasve unwarranted intrusion into your privacy.
Should we penalize Facebook for keeping our photos? No, that's what we use it for. Should we penalize shopkeeper for recording security videos of their store to help analyze thefts? No, that's within his rights. Should anyone be allowed to correlate all the images with all the security footage to have a camera-by-camera record of the motions of everyone in the city? No, that's a dystopian horror story in the making. The criminal intent is in the analysis, not the storage.
I once made a moderately interactive widget using pure CSS, and it was a relatively interesting experience. The widget itself had buttons that let you choose several parameters (about 400 combinations overall) and would render out a 'demo' of our product.
Some stuff I learned:
1. Most of css3 is supported in IE8, so we felt fine with using the widget in production.
2. With any reasonable LESS / SASS syntax, it's easy to generate complex stuff so long as it's limited to a discrete number of states. Stuff like tic-tac-toe are easily doable if you treat them as a state-machine.
3. It's way faster than JS, and there's a good reason for it. CSS can be totally figured out in one round of parsing, and so long as no JS is used to change it, the same parsed state can be used for all of your states. Even though it adds tens of kilobytes to the file size of both CSS and HTML, it's still faster than executing code.
This definitely isn't the right solution for all problems, but I think it's important to think about whether you problem can be solved in pure CSS, and to strongly prefer it for static sites and nearly-static sites.
There are a large number of issues for which there exist equally well-informed arguments for both sides, or that there is no actual 'true' answer to be chosen.
The first PC videogame I ever saw was a gorilla throwing a barrel at buildings. It was written in BASIC and came with our 286 back in 1989. I was really excited to learn how the monkey was drawn - out of the same ASCII blocks as everything else, obviously, but how? - and excitedly opened the file in a text editor.
It was a little overwhelming to my 7-year-old self to see just how many little subroutines and subprocesses were needed make the whole program work. It was a very complicated set of math processes, not unlike how a car engine is a very complicated set of physical processes. (I'd been helping with car repairs for a few years at this point, and rigged-up a pair of copper wires between the cable box and TV once when we only had 1 coax cable.)
Several years later, I was overjoyed to find the TI-82 calculators we were loaned in school could interpret the same BASIC commands, and happily started writing tiny utilities, competing with classmates for the coolest function, and joining debates about whether pre-programming the Quadratic Equation into a calculator counts as cheating on tests.
Despite setbacks like a lack of programming education in rural WA State in the early 1990s, that monkey throwing barrels planted the seed that made me want to write and understand software.
MSDOS 5 used to come with QBASIC. Nibbles and Gorillas were great games and they included all the source code.
I used to play Gorilla's all the time when I was a kid. That was how I learnt about angles. My Dad drew a picture for me "This is 90 degrees, This is 45 degrees" it used to sit beside the computer.
I learnt a lot about programming from the DOS environment come to think of it. Our home PC used to have a text based menu program it would boot into. In order to add a program to the menu you needed to edit it, using something like a markup language. My Dad used to sit over my shoulder and talk me through adding programs to the menu.
I don't think it's about being able to read text written in rows, although if you can't see that kids aren't particularly good at that initially, then you mustn't have spent much time with kids. (Hint, they learn to "read" with picture books and then books with like 5 words on a page.)
The same reason they learn to ride a bike on one with 12 inch wheels instead of 700c. Or cook using recipes with 3 ingredients.
Simplified versions for learning are a good thing.
First they grasp the basics using something simple, then they push the boundaries of that simplified version, and then they extend to the next step up.
Because they aren't very good at reading yet, because they're kids. And for some reason, kids often prioritize having fun over using the most efficient representation possible.
> Because they aren't very good at reading yet, because they're kids.
I'm not sure, but I think it may be the case that the best solution for teaching children programming at the point where "they aren't very good at reading yet" is to address that problem first. You can be a kid and be good at reading. I've known several, both when I was a kid myself and now that I'm an adult.
Exactly. I "learned" QBasic when I was 5-6 and it was really exciting because it was the actual language that implemented some of the games I liked playing. Kids like to learn about the real world. They can tell when you give them something simplified and they often don't like it.
When you're six you most likely can. And all those colorful blocks and smiling monkey-people look like something designed for one- or two-years-olds.
I was around 7 or 9 when I first saw QBasic. I definitely wasn't afraid of text at that age. The wonder of programming isn't in how it looks - it's in what it does.
The possibility, however remote, exists that you will randomly select a sequence with patterns and order. In cryptography, we define the term 'pseudorandom' in order to discuss a class of functions that look random.
Pseudorandom sequences are sequences where, given the first n bytes of the sequence, an adversary cannot guess the n+1th byte with probability significantly higher than 1/2.
Basically, it's important to distinguish between blindly selecting a sequence out of all possible sequences, and finding a particular sequence with no discernible internal order.
I used to have a version of that Dilbert comic as a forum signature for a while, except I hacked a little PHP script so it would insert a random number instead of "nine" into that panel (still repeated), different on every reload. Just to confuse people :)
CMSs are dying and static sites are replacing them - there's absolutely no reason to run a complex backend when the entire site is supposed to hold some text and maybe a space for comments.
Things like Jekyll or Hexo are straightforward and easy to work with, but because static sites are really just tools to transform markdown into HTML, something like Metalsmith could probably even handle online shops.
Static sites for large institutions is asking for trouble down the road.
Think about universities with hundreds of content providers. They'll put anything and everything on their sites with no regard for the standard layout/design. CMS gives them design choices, and enforces standards so you can update/refresh the look and feel in the future.
It's an easy distinction: if non-programmers are managing the content of the site, don't use a static site or a static site generator.
Asking people whose job isn't "building websites" to edit text files, run some sort of compiler on the command line, connect to a server via FTP, or deal with version control is a total failure mode.
But if a developer (or an especially adventurous designer) is going to be editing the content of the site as time goes on, then static files or a static site generator can be a great option.
> willingness to put ones life on hold for a predetermined amount of time.
That is almost the definition of a degree. During a degree, every class expects you to devote time and resources to learning. The degree programs we see today are structured in such a way that they expect you to drop everything else and learn (or research, in graduate studies).
If you can't 'put your life on hold' in order to study you won't be able to do it quickly or coherently enough to generate the large body of knowledge that a degree represents.
