Grey Smith

+ Follow
since May 24, 2014
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Grey Smith

What a great thread. I love how the focus is always on making the code easy to understand. If a long variable name is necessary to understand the code, then a long variable name is best, but as mentioned, it may be possible to refactor or place the variable in such a context so that a long name is no longer necessary to understand what the variable means. And the devil is in the details; without seeing and understanding the code in depth no good specific recommendations can be made.
2 weeks ago
Hi Wallace, I have a silly question and some serious ones. What's your favorite tag? Are there any tags that seems to be non-starters ( <dialog> <template> ?) , or that browsers can't get standardized on (like the different vendor-specific styles on <progress> ) ? Do you think that most companies/developers are ignoring HTML5 tags because they don't see the value in ARIA compliance and a semantic web? It seems like all the huzzah goes to Javascript frameworks and CSS gimmicks.
It might be whitespace changes. One version has a space and another doesn't; or one version has a tab character and the other doesn't; or one version has a Mac carriage return and the other has a Windows carriage return. Usually IDEs have an option to set what kind of carriage return you want in your project, and everyone who's working on the project should use the same kind of carriage return. On the command line, the command you can use to tell the difference is:

git diff --check

If you have colors configured right on the console you can then see the differences, and it'll also tell exactly what the whitespace differences are.
Git doesn't have a blanket command like that. It depends on where the "local changes" are.

If you have already commited the changes to your local repository (but not pushed them), you can destroy your last commit by typing:

git reset --hard HEAD~1

and the last commit will be gone. (It's not actually gone -- if you need to get it back, you can do a git reflog to see where it is. Git reflog shows you your history.)
This is considered a dangerous command because it can be difficult to track down the lost commit, and eventually that commit will be garbage collected. But it's also extremely useful, and it's very easy to find the lost commit if you use git reflog right after doing the hard reset. And it is less risky than the other options below.

If you haven't committed the changes, and you don't have any untracked files in the directory (untracked files = files that haven't previously been commited), go to the root directory of the repository, then do:

git reset

to move all files out of the staging area (the place files go before you commit them), and then:

git checkout .

to checkout all files from the last commit (and hence overwrite any changes you've made).

If you only want to get rid of some of the local, uncommited changes, in tracked files, you can run

git checkout -p

and then decide piece-by-pice which changes to keep and which to get rid of. (There are GUIs that make this process a lot easier.)

To get rid of untracked files, you can run:

git clean -f

which will delete them all.
None of these commands are safe in the sense of preserving the changes you made. In order to do that, your primary options are stashing them ("git stash -u", then you can use "git stash list" to view the stashes later), or commiting them (which you can do in a separate branch so that it doesn't get in the way of what you're currently working on).
In terms of reasons not to use testing frameworks -- in my very limited experience, they are often not easy to set up and they do not provide as much functionality as you would get were you to create your own testing set-up (I'm thinking specifically of testing private member functions in Java, although if I remember correctly (??) JUnit tests are supposed to exist in their own package, which really limits what they can do.). There's also a learning curve, which doesn't exist if you write your own tests from scratch.
As a caveat, most of my experience is with Javascript, in which every time I try to set up a testing framework, it takes so long that it is never worth the time. I would rather spend four hours writing thorough tests that execute every time I run the code than spend four hours writing no tests and perhaps not even completing the set-up required to use these vaunted frameworks.

Here's an example of a group of tests I wrote a long time ago without a testing framework. The background is that I wrote a strategy calculator for blackjack, and this tests one specific function (resolveHands) which does a certain set of calculations, along with some other functions along the way. It's not a good test, because (among other reasons) there's no documentation; there's no feedback presented when the test fails; it's not specific enough (it tests too many things); and there's no test description information which could optionally be shown on screen during successful tests; but it does demonstrate what you were asking about, a test without the use of a testing framework.

4 years ago
You should always wrap your XHRs in some kind of framework (one that you build yourself or one that someone has already built) which handles the icky details for you. jQuery is the most well known, but others are available as well, and it's not too difficult to build one yourself (though it's not worth the effort since there are fully functional, extremely well tested frameworks out there (like jQuery's .ajax)). The two primary reasons that you want to use a framework are to avoid code duplication and to ensure that your code is backwards compatible. In a modern web site you will make tons of Ajax requests, and if you write every one from scratch you'll be reinventing the wheel every time. As Bear's slide demonstrates, there are steps you'll have to take for every request -- adding a readystatechange listener, calling .send(), executing some code if the call succeeded (and presumably trying to parse the returned data if it's JSON; and that attempt should always be wrapped in a try-catch block), executing other code if the call failed, and adding a timeout listener (or using a polyfill if that event doesn't exist in the current browser). There's no point in rewriting that code every time since it's going to be the same. Also, whatever framework you use should handle any browser inconsistences for you (which means that you don't even have to be aware of them).

I second Bear's recommendation to always use JSON. Since Javascript is so loosely typed (a variable could be a number, object, function, or something else), many mistakes come from assumptions about the type of variables in your program. (Most of these mistakes are literally impossible to make in a strongly typed language like Java -- your code will be flagged instantly by the IDE and it won't compile.) So pay very close attention to what type your variables are. I use JSDocs with Webstorm -- Webstorm flags function calls which are using variables of the wrong type, which makes it easier to catch mistakes -- though there are probably some free alternative IDEs which provide the same service.
In terms of web sites, I recommend MDN (Mozilla Developer Network). W3schools has information that is incomplete and frequently misleading -- I never go there any more because the information I am looking for is rarely there, and if it is, it's not explained well or at all. MDN has good, detailed articles on HTML, CSS, and Javascript; they also link to the specs, which for me are typically too dense and specific to be useful (though they're the final word), but in dire straights that's where you'll end up. If you are building an actual web site, also check out, which tells you which HTML5/CSS3 features are supported by which browsers. MDN shows a compatibility box to give you an idea, but caniuse has the gory details that you need to make an informed decision.

I learned HTML from Jon Duckett's "Html & CSS." It goes slow enough that's it's pretty easy to pick up; it covers the main points you should know; and it's not a huge book. It's a little old (2011), but I still regularly pull it out to consult because it's so easy to find exactly what I'm looking for. It's a manual that covers the highlights, not a compendium.
but that's not what you're looking for so never mind.
In my limited experience, a status of 0 means that no reply has been received because there is no connection to whatever you're trying to connect to. Kinda like a 404 on steroids. When a server is completely down, and you try to contact it, you'll get that reply.
But as Bear was saying it's an asynchronous request, so you have to listen for the reply; you can't just check it directly after you've made it, because it's not done yet. Something like:

When "Yay my request is done!" prints to the screen, your xhr is finished and you can check xhr.responseText to see what data has been sent back (and xhr.status to check the status code). Note that you must add this event listener BEFORE you send the request; otherwise it won't work. A ready state of 4 indicates that the request is finished.
Fred -- Yes, I agree that programming is 90 % thinking. I'm surprised at how many people don't realize that. However, it is news to me if Agile does help anyone program. It seems a mass of status reports and paperwork (mostly on the computer, but same difference), and short meetings which rarely focus on any details or bring up different points of view.
I don't feel that I need a tool to tell me what the application needs to do. I think that common sense, and talking it over with whoever designed the app and the other people on the team (on a regular basis), can do that job. I know that applications should have as few bugs as possible and be easy to use and maintain. Sometimes figuring out how to make that happen is hard, and on a team it's important to pick a good strategy and have everyone stick by it.
I agree that good communication is important. I'm not going to straight up lie about not knowing something. I'm just not going to volunteer something that might make me appear less competent when I'm new at work. Just not smart to do that -- I don't think anyone can fault me for wanting to keep a job. My judgment of humanity is that we are unfairly judgmental towards other people ( ;) ), and I do not want to be judged.

Andrew -- I read the 16-page Scrum book Jeanne linked to. To me, how ideas are implemented are far more important that what they are in the abstract. Agile and other systems might sound great or awful in the abstract, but what really matters is how people actually use them. I don't put any stock in abstractions, buzzwords, corporate philosophies, etc., because most of the time they don't affect what actually happens day-to-day. Just a bunch of pretty words to dress something up. I have simple ideas about what makes a good workplace and a productive workplace -- open communication (which has to come from the top first as a sign of good faith), committed workers, and a willingness to talk about and accept criticism are three things that come to mind.
I'll glance over at the first chapter. And -- this is a promise -- if I do win a book copy I will read the whole thing.

Junilu --
1) Hm. It's a bit hard for me to separate out company practices and the Agile system since it wasn't explained to me. I feel like we rely too much on applications and virtual documents that are scattered in many places and all have their own logic about them. Learning them all has taken a good deal of time, and I think the tools are too specialized for the work I will be doing. It doesn't seem like there's much freedom yet in the ticket system -- that is, if say one bug is hiding three others, or if a bug and a bunch of other bugs are best dealt with by refactoring a large block of code, I'm uncertain that that would fit neatly in and be accepted. I also think that it's very hard to predict how long some problems will take, and that makes it difficult to be very definite about what will be done in a certain block of time. It's of course necessary to make predictions about what can get done, and without some kind of goal or deadline it'd be too easy for many people to slack off, so I can understand the necessity of structure.
2) …. I'm the new guy. No. Generally even if I don't like something, I won't say it until I'm completely sure about it, because rushing to judgment is very often a stupid thing to do. I'll still rush to judgment in my head, but I'll hold off on saying anything until I'm very sure, 'cause I know I could be wrong. And in the workplace I'm not going to say anything that's going to get anyone upset, unless there's really no choice and it's part of my job to do it.
3) I read the Scrum guide. I also do my best to understand all the tools and systems I'm supposed to use -- read the tutorials if I have time, or listen if someone is willing to explain it, or google it if I need to. Why I do things -- not exactly sure what you mean. I am at work to do what my boss says. That is what most jobs come down to. If you get really lucky then the job is mostly about doing a job, but that's only if your boss is a good boss and supports you in what you have to do instead of getting in the way. I get the feeling that programming is supposed to be professional job where there's lot of velvet on top of the you-are-at-work-to-do-what-your-boss-says, but really, that's what almost everything is.
I'm not trying to slink or be lazy or anything -- I really would like to do a good job.
4) No TDD -- I almost wish there was though because testing and documentation are an afterthought at best. I know there's supposed to be "continuous integration," which if I understand it right (working to produce software that is incrementally better and more functional) seems like common sense to me. Of course you should run your code all the time to make sure it works; it's nice to do tests on it all the time; and it's easier to fix bugs right when they come up -- so you should always strive for a working piece of software so that you know that your code does what you want it to do. Refactoring -- that might have a different meaning in the Agile world. To me it just means improving code that you already have and that already more-or-less works by doing things like adding documentation, making function/variable names more understandable, getting rid of repetitive code, making code more readable, creating new functions/classes to compartmentalize code better and make it easier to add functions/features or fix bugs, etc. I'm totally behind refactoring and when making a project bigger you have to do it on a continuous basis. Another benefit to refactoring is that you become more familiar with the code base, which makes it easier to use it effectively when adding features.

Jeanne -- Well, I really did owe you more courtesy. Even if I do doubt abstract corporate philosophies, I could have been a bit nicer to someone who thinks the opposite of how I do.
Thanks for the link. I'll read over it.
I don't mean to hinder anyone, and I do mean to do a good job. I can put aside how I feel about a particular corporate policy or process and work within its bounds, but when I'm not at work I don't have to act like I like it. I am sorry if I offended you. I acknowledge off the bat I don't know much about Agile, and that I wouldn't be posting if I didn't want to know at least a bit. (and where better to learn from than here where I can at least be honest?) If I felt secure that I would not be judged at work I would ask far more questions there, and probably do much better, but I've had enough bad work experiences to not be so trusting.
I just started a job which is evidently all about Agile -- there are daily "scrum" meetings, big boards with post-its on them which keep getting moved around and talked about, and someone who seems to be like a TicketMaster who gives everyone tickets to do. I've seen "story points" and other bizarre terms, and I'm sick of the phrase "as a user" already. I'm not really sure what's going on; no one has explained anything to me and I consider it too dangerous to admit my ignorance to everyone. (There is no private space at work and hence I can't speak to anyone in private. I find it a very chilling environment.) How can I fake like I know what's going on without having to read a whole book about it? (reading is not billable hours..) I'd rather focus on programming and not "Agile" and a bunch of other "tools" which seem to get in the way of me getting any actual programming done.
Hope you can provide a summary.
Hi John,
I was wondering how the atmosphere in programming work is different than in other lines of work. I have had a variety of jobs in other fields, but haven't worked in programming yet. I do feel like I have a leg up on recent college graduates, because I have enough work experience to understand how to be professional at work, to feel comfortable in identifying good and bad work situations, to stand up for myself when I'm able to, and to shut up when I can't do anything about a situation and saying something would just make matters worse. I understand that generalizations are often misleading, but how much respect would you say that programmers get compared to, say, unskilled labor, or college graduates who do not have specialized skills?
4 years ago
Hi Rami,
I've heard that Promises are to be implemented in the new ECMAScript 6 specification. Do you know what motivated this decision, and has any kind of research been done about the relative ease of using Promises as opposed to nested callbacks? I admit that I find Promises only a bit easier to use than nested callbacks, and far more opaque in terms of what's actually going on behind the scenes, though in terms of ease of use that's probably just my lack of familiarity. Are there alternatives to using Promises, other than nested callbacks and threads? (Not to say that Javascript should go down the road of threads -- I think that would be a big mistake.) I've also heard that Promises tend to obfuscate stack traces -- is that true, and if so, what is being done about it?
Thanks so much! I just started learning Javascript a few months back and so there's a lot I don't understand yet.
Hi, nice to be here.

Thanks for the rapid reply.

Great, that will save a bunch of time. Yes, I already have written and tested code for the files and arranged it to be easily portable for Android.
5 years ago
I have to store and retrieve 8000 elements of 500 bytes each, for an Android application. I only need to look at 1 element at a time, and it's okay if it takes up to a second to load, though faster is of course nice. (The "elements" are data blocks, not full objects, because ObjectOutputStream involves a huge amount of overhead because of how my objects are structured (I could override it but that's a separate issue.) -- it'd take at least 3x this amount of space if I used it. )

I have no experience in storing data apart from reading/writing individual files.

I have a key assigned to each of the elements, and I've written code to put each of the elements in its own separate file (with a checksum). But I think this might be a naive solution and an unwieldy number of files (the files never have to be altered, however, so it's probably just a question of installation time?). I have no experience with databases and don't really want to get entangled with them unless I need to.

Is having 8000 files feasible, or will it take way too long to install on certain devices? If I store 10 elements per file and have 800 files, is that far preferable, or is it easier to do some kind of database approach?
What are some easy ways to do this? (If there's a good site to explain these issues feel free to link me -- I'm really not sure where to look for this information)

Thank you for any replies
5 years ago