Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×

Comment Yes and No (Score 1) 667

I agree and disagree with the writer of the article.

On the one hand, there are a lot of silly rules floating around. The reason you shouldn't end a sentence with a preposition is because Latin doesn't. In fact Latin can't. The same goes for why you shouldn't split an infinitive. The infamous double negative used to be accepted English centuries ago, just as it still is acceptable in Spanish, French, and many other languages. I've come to think of it as a parity bit. Since one simple word flips around the meaning of the whole sentence, it's better to put it in twice.

But on the other hand, one of my favorite books is The Elements of Style. To its credit, it doesn't mess with chiding writers over ending a sentence with a preposition. It doesn't even advertise itself as a standard-bearer of "proper" English. It is mainly a collection of common-sense tips for improving your craft. It's most famous advice is "too omit needless words." It goes on to show you how to write clearly, rather than wishy washy. In short, how to serve the reader, and help him understand the information while wasting his time as much as possible.

Comment Re:Bubble Burst (Score 1) 107

It's 14/3/2015 in the sane world.

14 has no meaning outside of the month. 14 literally means the 14th day of the month. The month is the context. The fourteenth day of what? March. So when people say dates, it is perfectly normal to begin with the context and then the day. "What's the date?" "It's the month of March, and we are in the 14th day of it."

Why not then begin with the year, since that is the even broader context? "The year is 2015, in the month of March, on the 14th day." Because when people make appointments with each other, they do not normally make them more than a year ahead. "When shall we meet again?" "April 20th." It would be so unusual to make an appointment for April 20 of some other year, that we leave off the year. When we have to give a year --- "When was the Battle of Antietam?" --- we are already in the habit of saying month and then day, so we stick with it, and append the year, "September 17, 1862."

Comment Re:Bubble Burst (Score 1) 107

It's 14/3/2015 in the sane world.

Nope, it's 2015-03-14 in the sane world.

How do you say it? 3/14/2015 goes along with how Americans say dates: "March third, Twenty Fifteen." I suppose the European way, 14/3/2015, with its nice descending specificity, corresponds to saying "The fourteenth of March, Twenty Fifteen," or even as I've heard it said, "Fourteen March, Twenty Fifteen."

But in normal conversation do you say anything like 2015-03-14, like, "I will see you again on Twenty Fifteen, March 14"?

Comment Open your mind (Score 1, Insightful) 139

If my work didn't give me a laptop for free, I would be tempted to snap up a new Chromebook Pixel.

The self-anointed tech pundits are all scratching their heads. "Why such a luxurious laptop to just browse the web?"

"Just browse the web." That's the first lie. Web browsers, especially Chrome, no longer just browse the Web. It is no less than a modern GUI toolkit and practically a whole operating system. HTML 5 specifies that web browsers can run background processes, run offline, open and save local files, stream video, support instant chat, draw raster and vector artwork (<canvas> and SVG), and put up a large variety of widgets from just a little bit of code.

Chromebooks don't just browse the Web, they aren't useless offline --- or actually, Windows and Macs offline are just as useless, the way we use them today. About the only thing I'm still waiting on in a Chromebook is an offline video editor. Everything else --- word processing, spreadsheets, drawing, photoshopping --- are now available and pretty good. In fact, I think they're better, maybe just because they're newer, made by programmers who are wiser.

And who wouldn't want all the nice things in a Google Pixel: a solid build, a nice screen, a good keyboard, long battery life. The only point I agree on is that the processor is a waste, for most people. I would rather Google had gone for an ARM processor while keeping everything else the same, resulting in 24-hour battery life. I would rather get away with forgetting to charge my laptop one night than have that much speed.

Comment Re:But it's still a Chromebook... (Score 1) 139

it makes sense that a device that requires you use the Google office apps rather than native apps, would require you use considerably more memory and power.

Yes, it's ridiculous, but think of it like this: how optimal do you think a Google spreadsheet, implemented over JavaScript, the DOM, and XML, in turn implemented over various abstraction layers that eventually get down to C++ and some kinda linkage to the native widgets of the underlying OS, is, compared to a Microsoft/GNOME Spreadsheet implemented directly in C++, with a little abstraction but not a lot between that C++ and the underlying OS?

TL;DR: A device that forces you to run desktop apps inside a web browser will always need more power than a device that allows optimized apps to run.

Are you forgetting the other Chromebooks, all implanted with low-end processors? The Pixel is noteworthy because it's overkill. James Kendrick writes, "My old Acer C720 Chromebook had budget hardware when released, and still runs Chrome OS well." (Okay, his "old" Chromebook came out just a year ago. But still, it has a Celeron. Others have ARM processors.) The consensus is that Chromebooks are snappy no matter the hardware.

Comment Re:The Level of Abstraction (Score 1) 158

It amazes me how many people don't get this, and want to write a PHP "Front Controller" that uses a querystring parameter to select the "page", and then slap a mod_rewrite rule on top to clean up the URL. Instead of—as it sounds like you discovered—putting each page in its own file in the filesystem and letting Apache "route" the request.

Right. I split the program into more files, instead of mod-rewriting everything through a gigantic PHP controller. Of course any database-backed app must eventually resort to the query string, PATH_INFO, or something. I usually use those to specify just the record ID or search filter, not an app section. Each section gets its own file.

Comment Narrow Subject (Score 1) 247

The study was over a single application. From the article:

The researchers selected a small-scale application (about 4,500 lines of C# code) used by the academic staff at the University of Kelaniya for scheduling events and managing online documents for evaluation. 10 common refactoring techniques were applied to the code (e.g., Replace Type Code with Subclasses, Replace Conditional with Polymorphism).

Not only did they study just one application, but they limited refactoring to these 10 fancy techniques specific to object-oriented programming (from the research paper itself):

R1- Introduce Local Extension
R2- Duplicate Observed Data
R3- Replace Type Code with Subclasses
R4- Replace Type Code with State/Strategy
R5- Replace Conditional with Polymorphism
R6- Introduce Null Object
R7- Extract Subclass
R8- Extract Interface
R9- Form Template Method
R10- Push Down Method

In contrast, here are some things I do when refactoring:

- escape HTML in variables before embedding them in HTML, to seal against scripting attacks
- rewrite database queries to use parameters, instead of variables directly from user input, to seal against SQL injection
- move repeated code into functions
- Make app use just one database connection library instead of two. Yes, that's right, the app made two connections to the same database, through two different PHP libraries, on the same page. The only reason I can guess is that the last programmer meant to move from one library to the other, but left the company when he was right in the middle of doing so.

and a dozen other basic programming techniques. You had better believe that such refactoring improved code quality. Typically the code shrinks down to 30-70% its original size. Often it runs several times faster. For sure it is safer. And having merged code that was copy and pasted all over the palce, it is a lot easier to make changes to thereafter.

Theoretically, I shouldn't have to do these kinds of things, because a professional programmer should not strew such code behind them. But every single one of my fellow programmers or forebears here has committed these atrocities. For what it's worth, I work on a corporate intranet. So I probably see worse acts than at companies dedicated to software.

Comment The Level of Abstraction (Score 5, Interesting) 158

You will always have to write some code of your own. Even if you use a CodeIgniter, AngularJS, and every prewritten function on StackExchange, still, you will have to write some code to configure the frameworks and to pull it all together.

You will always use some of someone else's code, too. Aren't you using Linux or something? You didn't write your own OS, did you? You're using a database, like MySQL or PostgreSQL or something, right? You didn't write your own database system, did you? And are you using a web server like Apache or Nginx?

So the question is not, should I write my own code or use someone else's. The question is where to draw the line.

I'm a web programmer, your typical LAMP developer (well, LAPP --- I use PostgreSQL). Like many PHP programmers, I first concentrated too much on the PHP. PHP is not the best language, as many have said, but I don't think it's quite as bad as people make it out to be. Anyway, I never took up any of the PHP frameworks. They seemed like too much trouble to adapt. (I should point out that I started with an intranet with a dozen or so applications already built.) I would research PHP frameworks from time to time, but always rejected them all, and felt a little self-doubt in doing so: "Do I suffer from Not-Invented-Here Syndrome?"

But PHP, and scripting languages in general, provide the right level of abstraction, I think. It takes care of memory management. It provides a bunch of functions for HTTP. It has its own templating syntax. It's great if you don't overuse it. In other words, in the MVC pattern, PHP does great for the View and, together with Apache, the Controller. But if you write a lot of your Model in PHP, with all this data processing, checking, calculations, etc. --- well, that's what the database is for, I think.

So, instead of eventually adopting a PHP framework, I learned more and more about Apache and PostgreSQL, and I learned that a lot of the things that I was doing in PHP could be done in SQL or in the Apache configuration, with a lot less typing (a lot more reading but a lot less typing). While most people are busy trying figure out how to write the practically all of the MVC in PHP, I realized that Apache was part of the Controller, PostgreSQL was part of the Model, and the browser was part of the View. I use PHP just to help them out, only when needed.

Slashdot Top Deals

The one day you'd sell your soul for something, souls are a glut.

Working...