×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Happy New Year. Same As The Old Year.

tomhudson (43916) writes | more than 2 years ago

Medicine 10

Last year started with my left retina bleeding, followed by a year of treatments to both eyes. By the last hospital visit (end of November), things were looking good. Not perfect, but "good enough".

Last year started with my left retina bleeding, followed by a year of treatments to both eyes. By the last hospital visit (end of November), things were looking good. Not perfect, but "good enough".

But yesterday (this New Years) I noticed a small blotch. And this morning it took a while before either eye would focus all that well. And of course, after a while writing code, the left eye began to hurt ... and it then bled some more. So I took a break. 4 hours later, I'd say it's back to where it was about 4 months ago.

It's not my nature to give up, but this is cutting it too close for comfort. I already figured that nobody's going to hire a programmer who misses 30 days or more a year ... but this also puts in question whether I can even complete stuff on my own - it takes time to "get back into it" after taking a few days as a "break" as is, but if I have to limit it to an hour or two a day even when things are going relatively well ...

... if it were someone else in the same situation asking my advice, I'd tell them to stop banging their head against the wall, face the inevitable, and give up gracefully so that they can move on. Not that there's much to "move on" to, given how limited my options have now become.

10 comments

what dpi are you programming at? (1)

Bill Dog (726542) | more than 2 years ago | (#38566888)

I got a 27" at 1920x1200 for my current home PC, that's a relaxed .30 dot pitch [I really like this guy's calculator page [members.ping.de] ], and comfort-wise there's a noticeable difference to me between this and the 24" at 1920x1080 at work, where with the latter I feel some eye muscle and/or blood vessel strain I guess and get some redness and dryness after reading code on it all day and with the former I have nada. I have subdued lighting in both places and the monitor brightness turned way down, so that shouldn't be a difference. And no direct light sources within my direct nor peripheral field of vision. (Or maybe I'd wear one of those green bookkeeper visors!)

Getting more drastic, I wonder if this would work: I'm currently drooling over the idea of one of those 2560x1600 monitors. In a non-existent 24" for that res, that would be like 4 of my 12" netbook's 1280x800 panels glued together. I hate LCD's at a non-native resolution for text, but theoretically it would look just fine set to exactly half its native one. That might afford you some huge-but-sharp text, and it's not like we didn't use to program at a skimpier 1024x768, once upon a time.

I'd try add'l ways of accomodating my body before abandoning what I know and love. (Maybe, as a last ditch effort, try for teaching, where you're spending more of the time looking at a classroom of students and large, projected code?)

Re:what dpi are you programming at? (1)

tomhudson (43916) | more than 2 years ago | (#38569174)

My screens are both Samsung T260 [samsung.com] 1920x1200, 25.5", which gives .286 dot pitch.

I'm running them at 120dpi instead of 96 dpi, which scales things up by 25%. That is simply nowhere near enough. Until tonight, I was zooming in web pages at ~150%. Now I'm trying 200%, which given the 25% boost from the higher DPI, really translates into someone viewing at 96DPI at 250% ... it seems to help ...

I was already using an 18 point monospace font for coding - I've just bumped it up to 24 point ... but that's like using a 30pt font on a 96dpi rendering ... it's HUGE. BUT I can read it with noticeably less strain, so here's hoping ...

Stupid coding tricks to make for easier reading

The rule is - the less verbose the code, the easier it is to read.

# 1: Convenience functions

We all have them. I've just made mine more "going-blind-friendly" with a set of all-uppercase convenience functions - so instead of looking for something like parseInt(foo) , it's just INT(foo), IADD (a, b, c, d, e ...) for when I want an int, ADD(a, b, c, d, e ...) for when I want a float, ARGC() instead of arguments.length, ARG(i) instead of arguments[i], ARGS() instead of arguments, etc.. It's a lot easier to scan code to find LEN(whatever), SPLIT(url, PROTO_SEP,), MIN(a, b, c), INC(i, j, k ...) DEC(left, 20) and PUSH(THIS) ...

#2: A global STACK

Yes, I have a global STACK on which I can PUSH(foo, bar, baz) and POP() things ... (and an SP so I can peek into the stack if I need to preserve the same args for multiple calls). It's easier and less error-prone to just push a few things on the stack and re-use them than it is to type in a bunch of parameters when I need to call the same routine between 3 and 9 times in a single function, depending on what's happening ...

Using a global THIS, and being able to push it on the stack, then have another function overwrite the global w/o having to worry about it also means one parameter less in many function calls, such as array or object initialization. One parameter less is a Good Thing(TM). It may seem cumbersome at first, but you get used to it quickly enough.

So what if it looks a bit like assembler ... it works (and I'd KILL for a goto instruction so that I could implement JE, JNE, JGE, JZ, etc. properly)

#3: No Get/Set functions

Which would you rather type, scan for typos, and debug?

1a. left = document.getById("widget").style.left; // get widget.style.left
1b. document.getById("widget").style.width = 400 + "px"; // set widget.style.width

- or -

2a. x = XByID(widget); // get widget.style.left
2b. CXByID(widget, 400); // set widget.style.width
or
2c. CXByID(widget) = 400; // also works

I have always seen that as clumsy when you can just either overload the function, or count the # of arguments. If it's 1, return the value, if it's 2, set it. It's always worked in c++, and in c with variable argument lists ... So ByID("widget") returns a reference to the widget, HTMLByID("widget") returns the innerHTML of the widget, and the same HTMLByID("widget", "Hello", "people") sets the widgets' innerHTML to "Hello people". (automagically adding a space between each parameter :-) CursorByID(), YByID(), CXByID, SrcByID(), OnMouseDownByID(), etc. because less typing also means less scanning code to find something or fix a bug... it's also pretty much self-documenting, so I don't have comments except for a header that lists the mods for that version, the public functions, and the private functions.

I (sometimes) make an exception for "private" functions - functions that the main code never calls directly - both for runtime efficiency's sake, and to mark these as "private" in my own mind.

#4: Constants, LOTS of constants

It's a lot easier to pick out case THREE: than it is case 3:, or case IS_NULL:, case HTTP: case FILE: etc., (and notice that you're missing a case). Same with for() loop variables, so even trivial but oft-used values get constants. Page elements also get constants, so ByID("Alert") is really written ByID(Alert) - less typing, AND if I mistype Alert, it's flagged right there instead of further down the road finding out that ByID("Alertt") - with an extra "t" - returned a null reference.

Also, it's easy to find a bug when you get a "not defined" error for a constant.

#5: Exploiting the array/object duality in javascript

The same thing applies to array fields. One little-known "feature" is that you can do this:
var ClassNameField = "ClassName", IDField = "ID";
var Stuff = new Array();
Stuff[ClassNameField] = "AlertWidget";
Stuff[IDField] = Stuff.ClassName; // no need to add the "Field" suffix after initialization

Notice that I do NOT need to worry about adding "Field" any more, either when using an array-style ["name"] reference - which I also do not need to put in quotes - or an object.name reference. I also get a bit less worry about typos this way.

#6: Lots of ternary one-liners

Yes, people hate things like x = (cx > 20) ? x +10 : y - 40; but once you get the hang of it, it really does make for more compact code. Consider x = (obj == NULL) ? ERR_NO_OBJECT : obj.X; More compact code is easier to visually scan, especially when you make your fonts so big that instead of having 60 to 100 lines visible, you feel like you're back in the Hercules green-screen / amber-screen days. Terseness is my friend.

#7: If it's more than 80 columns, find a way to reduce it.

This might mean collapsing a complex (((ByID(FooBinBaz) + "TAG_SEP + 43 != NULL) && (Foo.CX > 4) && (Foo < Bar)) || (Bar > Blech + 20)) into a function call to verify parameters. If that's what it takes, it is what it is ... the goal is to make every line quickly readable w/o having to scroll left/right, and without having to have a single logical line take up more than 1 physical line. It also means that "syntax error on line 67" means just that physical line - not it + the next 3 logical lines.

#8: Lots of small source files instead of fewer large ones

Nothing worse than having to hunt around in a 1,000-line source file.

#9: Use the STACK to reduce typing and make code more generic

Consider this:

function NewIcon(name, num) {
var THIS = AINIT(); // create new array
AADD(ClassName, name + Icon); // Icon is predefined as "Icon"
AADD(ID, THIS.ClassName + "_" + num);
PUSH(THIS, name, num);
NewWhatever(); // NewWhatever overwrites the global THIS
THIS = POP();
AADD(OtherField, POP());
AADD(Src, "img/" + THIS.ClassName + num + .png");
AADD(Show, FALSE);
AADD(CX, 24);
AADD(CY, 24);
AADD(CSS, "cursor:pointer");
return THIS;
}

This is easy to type, generic as all heck, and easy to re-use via both copy-pasta and pseudo-inheritance.

#10: Use data structures to hold the current state

Only update the screen widgets and UI to reflect the underlying data structures.

A typo in manipulating your data stores is a lot easier to find than one that directly manipulates on-screen widgets. So, you have a title bar?

var THIS = AINIT();
AADD(IDField, MyTitleBar);
AADD(FgColorField, "White");
AADD(BgColorField, "ForestGreen");
AADD(TxtField, "Hello, world");
AADD(CYField, 24);
AADD(CSSField, "font-weight:700;font-style:oblique;text-align:center"); MyTitleBar = THIS;

Then, later on ...

Title.Txt = "some text";
Title.BgColor = "SkyBlue";
RedrawTitle();

By always maintaining your data structures as the source of any UI "painting", you simplfy things like redrawing, knowing the current state, etc ... and serializing / unserializing become a LOT easier.

It's probably not anyone elses' cup of tea, and some of it may seem like overkill or just plain stupid, but it all helps to reduce the visual "work" required, both in writing, and in debugging.

Re:what dpi are you programming at? (1)

Bill Dog (726542) | more than 2 years ago | (#38570268)

My 2 cents, in no particular order:

1) Making js look like asm, or any language look like another language for that matter, is awful.

2) Using unnecessarily broad scopes, like globals, is sloppy.

3) For convenience functions I've recently learned the jQuery library, which has a large shared appeal vs. one's own personal library. I like the explicitness of

x =$('widget').left();
$('widget').width(400);

versus having to remember that different numbers of arguments set totally different properties.

[...]

Okay, scratch that, I just now noticed that one of those calls is "XByID" and the other is "CXByID". Yeah I definitely like ".left" and ".width" more, for better readability.

4) I wish js had constants. You prolly aren't wrapping them in closures with privileged methods to enforce a read-only status on them, so you're using variables and hoping that they never get changed anywhere. (Or worse, using non-standard proprietary browser extensions.)

5) My understanding of js arrays is that they're simply objects but with add'l built-in methods. Nothing you're doing in the short code snippet in your #5 requires an array.

That is, you can take *any* object and add an "expando" property to it with either the dot notation or the square bracket notation (where with the associate array syntax the property name has to be a js string expression, either a variable or a literal.)

6) Js arrays have push() and pop(), and can take anything.

7) Instead of building up an object with a sequence of calls to a custom method

AADD(FgColorField, "White");

why not just use object literal syntax

var that = {
ID: MyTitleBar,
FgColor: 'White', ...
};

It doesn't seem like you really need to be inventing all this custom stuff. (That is, except for maybe all the SHOUTING aliases that are easier for you to see.)

Re:what dpi are you programming at? (1)

tomhudson (43916) | more than 2 years ago | (#38572152)

Pet peeves time :-)

The goal wasn't to "make it look like asm - however, asm IS noted for its' terseness of each instruction, as opposed to, for example.ThisIsAReallyLongNameOfSomeStupidThingInJava.getTheWorstWayToRedrawThisThingAndDoIt(); And there are some good programming idioms.

Globals are not necessarily a bad thing, and having a global stack comes in handy - esp. since you can't reference a local stack from another function unless you pass that as well, which defeats the point of having a stack. I have one function that needs to make between 3 and ~30 calls to the same sub-routine, depending on the context. I can either use two globals reserved as "registers" for integers (INT0 and INT1) for two of the variables, and just pass the other two in each function call, or pass 4 variables. Guess which is easier to write, runs quicker, and is easier to maintain. The same with pushing things onto an array without having to give the name of the array - both one parameter less, and more generic, so easier to maintain, and easier to reuse. BTW - jQuery also has a global stack variable.

I *hate* top, left, right, bottom, width and height. Waaaayyy too much typing. Have hated it since Delphi (where I modded my library to replace them with x, y, cx, and cy, and also to add x2 and y2). x, y everyone understands as the upper-left point of a box. cx and cy (change in x, change in y) are pretty universally understood as width and height (why that instead of "d" for delta, I don't know ...), and x2, y2 are obviously right and bottom coords of the same box. Then, have the helper functions add and remove "px" as necessary between the array data stores and the on-screen elements.

The jQuery $ function (which is just a function named $ - it could have been named Foo) has more overhead than my approach. So does the rest of the library. It also does something that I *refuse* to do - eval(code). There's no need - ever - to eval *anything*. Fix your code so that you already have your objects pre-defined, or do like I do, array (not object) syntax, and you NEVER call eval. Array[blah] always works, and never drops out of interpreted mode to call the js compiler to stop and eval() anything at runtime. My way, I can pass both data and "objects" to and from the server at runtime w/o calling eval() at any point - though I won't pass objects - just data - on general principles. Eval is evil. It's SLOOOWWWW. It's a gaping security hole. Using it makes programs harder to debug. Why bother?

Also, I remember you saying you don't like it when a program modifies standard things (like the document or window object) by adding new methods directly to it (such as window.prototype.foo = foobar;) - if you look at the source, jQuery does this.

Now, since I have to go to the hospital next week for blood tests anyways ( and I *know* my eye specialist will be there that day, and it's *****COLD -17 COLD***** outside), I'm going to try holding off and see if things don't get worse, now that I've made the fonts much bigger.

TTYL

Re:what dpi are you programming at? (1)

Bill Dog (726542) | more than 2 years ago | (#38580622)

I see your points to some extent. But then it's hard to be disagreeable when it's winter and yet where I'm at the sun's been shining and it's hitting the high 70's! :P

On jQuery, from the latest [aspnetcdn.com] it looks to me like the only place eval() is used is to run the return data of an ajax call if it's js. I haven't done any ajax with jQuery yet, but I would think there must be some way to disable that auto-execution feature, in case you're calling into a site and it's been hacked to return malicious js.

But on adding to the prototype of standard objects, it was (notably) Prototype and every other library *except* jQuery that did that. And these others have been switching over to wrapping instead of directly augmenting.

I hope 2012 is a year of healing for you, and of arriving at satisfactory adaptations.

Re:what dpi are you programming at? (1)

tomhudson (43916) | more than 2 years ago | (#38581200)

The high 70s, hmmm? Nice!

Thanks for the sentiments. I think the xx-large fonts are helping a bit, but it's still actively leaking into the eyeball ... maybe tomorrow will be better. :-(

Re:what dpi are you programming at? (1)

joshuac (53492) | more than 2 years ago | (#38632420)

My screens are both Samsung T260 [samsung.com] 1920x1200, 25.5", which gives .286 dot pitch.

I'm running them at 120dpi instead of 96 dpi, which scales things up by 25%. That is simply nowhere near enough. Until tonight, I was zooming in web pages at ~150%. Now I'm trying 200%, which given the 25% boost from the higher DPI, really translates into someone viewing at 96DPI at 250% ... it seems to help ...

I was already using an 18 point monospace font for coding - I've just bumped it up to 24 point ... but that's like using a 30pt font on a 96dpi rendering ... it's HUGE. BUT I can read it with noticeably less strain, so here's hoping ...

Your strategy seems to be to make things larger, as if you were trying to cope with a minification (as in optics, not programming) problem. Have you experimented with radical adjustments to the distance of the object your eyes are focusing on? Relaxed the human eye focus is at infinity; think scanning the horizon for threats, with occasional refocusing on a near object before going back to scanning for stuff moving in the distance. Focusing on something a meter away all day long for years on end isn't what the eye does gracefully.

trying 200%, which given the 25% boost from the higher DPI, really translates into someone viewing at 96DPI at 250% ... it seems to help ...

I didn't have your condition (in my case just plain old "eye fatigue"), but realizing focal length was the root cause and adjusting for it led to a dramatic improvement after years of experimenting with image scaling in exactly the same way you are. Image scaling helped with the symptoms (I could see what was happening easier) without any effect on the root cause.. In my case the difference was immediate and dramatic enough to notice after a weekend of playing games on a friends projector, leading to my adjusting my work environment for longer focal distances, so perhaps you could find out if focal length is or is not a factor in your condition just as quickly if you haven't already.

Re:what dpi are you programming at? (1)

tomhudson (43916) | more than 2 years ago | (#38633342)

I've got a "stalk" of blood vessels that burst right over my left fovea (the tiny part of the retina responsible for all your sharpest vision) - the problem isn't focusing so much as having "gunk" in the way. Making things much larger means the gunk doesn't block out as much information so I can still figure out what's on the screen.

The other problem is that vision problems in one eye ultimately affect both eyes - both in increased work-load, and in trying to figure out what is really there and should be focused on by both eyes, and what's just an artifact and should be ignored. When it's stable, the eyes and brain learn and adapt, but when it changes rapidly, like when it started bleeding again last week, it's a real problem.

And of course, when it gets painful, that's a message to stop whatever I'm doing and go lie down, to reduce the inter-optic pressure. At one doctors' appointment, I met a patient who had to give up yoga because just bending down would cause enough of an increase in blood pressure to literally "pop a vessel". The risks don't stop there - the inertia of the extra mass of the blood vessels on the surface of the retina can cause the retina to distort, and ultimately even detach, another emergency situation.

Even the smallest of distortions can cause artifacts, such as light flashes [wikipedia.org] .

My biggest concern, obviously, is preventing it from getting to that point in my "good" eye. While it's "inevitable", there are different definitions of "inevitable", so I'm counting on a YMMV scenario and one good year to make a stab at doing something that will work out for me medium-term, because it's obvious that (1) the clock is ticking, and (2) nobody's going to hire me with such problems, and (3) even if they did, it's not a solution.

Damn. (1)

Doctor O (549663) | more than 2 years ago | (#38589948)

Sucks to hear this. OTOH, I second the notion of becoming a teacher. I've learned more from tangents of your comments than I learned from my whole professional training. Even if I usually don't adapt your ways of doing things, they show me other perspective and help me grok the underlying principles. This, IMHO, is the most essential part of teaching.

Re:Damn. (1)

tomhudson (43916) | more than 2 years ago | (#38591224)

AB DEF .. AB DEF ... AB DEF ... AB DEF - long time, no C!

Thanks for the feedback. I'll keep it in mind if my current code idea doesn't work out. It's going slower than I'd want it to, obviously, because of all the problems, BUT I *am* still making progress - enough that, if things go okay, I should be able to post a url for the demo some time this weekend.

If it doesn't work, I'll probably sit down and write my book ... I've got lots of "interesting" things to write about that I haven't touched on here ... (and there would undoubtedly be much wailing and gnashing of teeth ...) ... but I'd rather it works.

So, how's by you?

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...