Referencing Android layout elements before defining them
Occasionally it’s convenient to have an Android RelativeLayout
that references another layout element that hasn’t been defined at that point in the XML file. E.g.:
Occasionally it’s convenient to have an Android RelativeLayout
that references another layout element that hasn’t been defined at that point in the XML file. E.g.:
Over the years, I’ve used a variety of editions of Eclipse with a variety of plugins. These days I try and minimize all of that and ask Eclipse to do as little as possible as infrequently as plausible. The below is a diary of sorts of the events that led to that choice.
A selection of ways Eclipse has failed me:
eclipse.preferences.version=1
org.eclipse.ui.commands=<?xml version\="1.0" encoding\="UTF-8"?>\n<org.eclipse.ui.commands>\n<activeKeyConfiguration keyConfigurationId\="org.eclipse.ui.emacsAcceleratorConfiguration"/>\n<keyBinding commandId\="org.eclipse.jdt.ui.edit.text.java.search.references.in.project" contextId\="org.eclipse.ui.contexts.window" keyConfigurationId\="org.eclipse.ui.emacsAcceleratorConfiguration" keySequence\="COMMAND+SHIFT+V"/>\n<keyBinding commandId\="org.eclipse.ui.window.previousPerspective" contextId\="org.eclipse.ui.contexts.window" keyConfigurationId\="org.eclipse.ui.emacsAcceleratorConfiguration" keySequence\="ALT+COMMAND+CTRL+ARROW_LEFT"/>\n</org.eclipse.ui.commands>
overridepresentation=true
Normally I could care less what format software stores its config files in, but despite the braindead format I’ve still had better luck editing this file by hand than trying to get Eclipse to handle it correctly. If your config file format is too error-prone for your software to handle, maybe it’s time for a change.
Stack Overflow requires that questions be largely objective, but is based around a voting system that would be largely unnecessary if all questions actually were. The requirement for objectivity can be readily tested by asking a subjective question and watching how quickly it’s removed, but it’s also made explicit in their blog posts:
Stack Exchange is about questions with objective, factual answers.
…open-ended questions diminish the usefulness of our site…
and the reasons a question might be closed:
We expect answers to be supported by facts, references, or specific expertise, but this question will likely solicit debate, arguments, polling, or extended discussion.
The message is quite clear: objective good, subjective bad.
Borrowing an idea from Jeff Atwood, here is a list of misconceptions about how Stack Overflow should be used that are common enough to warrant rote responses.
On larger Git projects, I often see the following scenario play out after someone’s done some work and is ready to push it to the remote repo:
...making and committing changes to "develop" branch...
$ git pull
Already up-to-date.
$ git push
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 363 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To git@github.com:test-repo/test_repo.git
e8c1210..1a0c4d4 develop -> develop
! [rejected] new_feature -> new_feature (non-fast-forward)
error: failed to push some refs to 'git@github.com:test-repo/test_repo.git'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again. See the
'Note about fast-forwards' section of 'git push --help' for details.
In my last installment we looked at all the reasons why editing video isn’t as easy as it should be. Let’s assume that we’ve cleared those hurdles, and now actually want to do some video editing from the command line. A not-uncommon video effect is fast- and slow-motion, sped-up or slowed-down video. Being common, you’d think it would be readily available in any video editing software, but you’d be wrong. Out of respect for all its other virtues, we’ll be using ffmpeg today.
Pop quiz!
Given (A) foo.mov, (B) bux.avi, and (C) baz.m4v, which can your video software handle correctly?