You might be doing some spring cleaning to your source code, or you might move files around that you think are unnecessary. Later on, you realize that one of the files you removed was a dependency. Now what? For this, we use git checkout.
If this is you:
...edit files...
git add edited-file
git commit -m "made changed"
git rm seemingly-useless-file
git commit -m "removed unreferenced dependency"
... edit file ... realize you dynamically included that file elsewhere..
Then you can simply follow up with:
git checkout 0a323 // the previous revision (hash from `git log`)
cp seemingly-useless-file seemingly-useless-file.1
git checkout master
mv seemingly-useless-file.1 seemingly-useless-file
git add seemingly-useless-file
git commit -m "Restored seemingly-useless-file"
You may want to git blame yourself while you’re at it.
If you know of a better way, please let me know.
Tags: backup, branch, checkout, commit, deleted, file, git, recover, rename, restore
Posted by Chief on Jan 19, 2010 in
Lessons I’ve discovered that icons given headings in Google Earth KML stopped orienting in the specified heading direction. The result is that when a user rotates the Earth so that true North is not directly “up” on the screen, the angle of the icon is misleading. For wind barbs, this could lead to dangerous decisions being made if the viewport isn’t manually corrected to set up = true north.
There are several known branches of this problem.
One involves the Google Earth browser plug-in:
Apparently, this incorrect handling is the end result of a bug fix to “correct” icon heading behavior.
Google Earth Plug-in – 5.1.3506.3999
(Issue 131) Icon headings should now behave as expected, and consistent with the Google Earth desktop client.
http://www.noeman.org/gsm/mac-other-oses-softwares/106515-google-earth-google-earth-plug.html
More on this bug (affecting version 5.1.x): http://www.google.com/support/forum/p/earth/thread?tid=005bea9c26949e40&hl=en
Work-arounds: GroundOverlay and use a Colada model, both ugly.
Another instance of the icon heading bug:
There is another situation in which the heading of the icon is not obeyed. This occurs when an invalid styleUrl is used in the KML. One recommendation is to remove the “#” character. ex: <styleUrl>#balloonStyle</styleUrl> is no longer correct as of version 5x. I have not confirmed this, but I’ve heard that this is correctly implemented as <styleUrl>balloonStyle</styleUrl>. What happend? This isn’t very backwards-compatible nor user-friendly. Why the change? HTML hashes are logically sound, as they refer to a locally named entity, such as those specified by a style id.
What worked for me was to completely remove the styleUrl when providing a local Style. See below.
Broken:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
| <?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2" xmlns:gx="http://www.google.com/kml/ext/2.2" xmlns:kml="http://www.opengis.net/kml/2.2" xmlns:atom="http://www.w3.org/2005/Atom">
<Document>
<name>Weather Stations</name>
<description><![CDATA[<p>Generated: 2010-01-19 22:03:45 UTC</p> <p>Only stations reporting <b>within 3 hours</b> are included in this document.</p>]]></description>
<open>1</open>
<Style>
<ListStyle>
<listItemType>radioFolder</listItemType>
<bgColor>00ffffff</bgColor>
<maxSnippetLines>2</maxSnippetLines>
</ListStyle>
</Style>
<Style id="balloonStyle">
<BalloonStyle>
<text><![CDATA[
<h2 style="font-size:1.1em;border-bottom:solid #333 1px;">Instrument:
$[name]</h2>
$[description]
]]></text>
</BalloonStyle>
</Style>
<Folder>
<name>Visibility and Avg Winds</name>
<Style>
<ListStyle>
<listItemType>checkHideChildren</listItemType>
<bgColor>00ffffff</bgColor>
<maxSnippetLines>2</maxSnippetLines>
</ListStyle>
</Style>
<visibility>0</visibility>
<Placemark>
<name>Any Instrument ID</name>
<description><![CDATA[ <p><font color="#999">Sample Date</font></p> <div>Data Table Here</div>]]></description>
<styleUrl>#balloonStyle</styleUrl>
<Style>
<IconStyle>
<scale>3.25</scale>
<heading>0</heading>
<Icon>
<href>http://www.example.com/barb.php?spd=4&dir=74&val=7&col=65280&dia=100</href>
</Icon>
</IconStyle>
</Style>
<Point>
<coordinates>-117.1135,32.3325,0</coordinates>
</Point>
</Placemark>
</Folder>
</Document>
</kml> |
Working:
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
| <Placemark>
<name>Any Instrument ID</name>
<description><![CDATA[ <p><font color="#999">Sample Date</font></p> <div>Data Table Here</div>]]></description>
<Style>
<IconStyle>
<scale>3.25</scale>
<heading>0</heading>
<Icon>
<href>http://www.example.com/barb.php?spd=4&dir=74&val=7&col=65280&dia=100</href>
</Icon>
</IconStyle>
</Style>
<Point>
<coordinates>-117.1135,32.3325,0</coordinates>
</Point>
</Placemark> |
Tags: bug, google earth, heading, icons, mapping, wind barb
Posted by Chief on Jan 12, 2010 in
Lessons,
Quotes Everyone wants a baby, but no one wants a kid these days.
Runaway1956
Kids today get emo and suicidal because they have been given everything, never had to earn anything, never been hungry, never had anything real to fear, never been punished for their behavior and are bored with having too much entertainment.
Nadaka
Tags: add, adhd, bored, children, depression, emo, generation, right, spoiled, wrong
Posted by Chief on Nov 23, 2009 in
Lessons Premise: There are two ropes of equal length and physical composition. Each rope takes one hour to burn from end-to-end, but may burn at a variable rate. You are given a lighter and these two ropes. There is nothing else that can be utilized, not sand nor clock nor sun.
Question: How can you determine when 45 minutes have elapsed?
Answer: Light one rope at both ends. Light the other rope at only one end. When the rope that was burning from both ends has burnt out, 30 minutes have passed. Light the second end of the rope that was only burning from one end. This rope will burn out in 15 more minutes. The total time will have been 45 minutes.
Tags: burn, riddle, rope
Posted by Chief on Nov 4, 2009 in
Lessons
- Failing to plan for scaling out, scaling up
- Not using EXPLAIN (learn from your mistakes)
- Using the wrong data types (hint: use smallest fixed-size)
- Using persistent connections in PHP (leads to zombie processes)
- Using a heavy DB abstraction layer (hint: use PDO or custom)
- Using the wrong storage engine (MEMORY, ARCHIVE, InnoDB, etc.)
- Using indexes improperly (hint: select in the order of the index; hint: keep primary key small)
- Issuing SQL queries that can’t be cached easily; having too large of a query cache
- Using stored procedures when prepared statements are better
- Using functions on indexed columns in the WHERE clause
- Not indexing important columns; having redundant indexes
- Using sub-queries when joins would be better
- Issuing avoidable deep scans
- Doing SELECT COUNT(*) without WHERE on InnoDB table.
- Failing to profile/benchmark your SQL
- Not using AUTO_INCREMENT if applicable
- Not using ON DUPLICATE KEY UPDATE (1 query vs 2)
Reference:
Tags: mysql, optimize, pdo, performance, sql
Posted by Chief on Nov 3, 2009 in
Lessons,
Quotes I have never thought of writing for reputation and honor. What I have in my heart must come out; that is the reason why I compose.
Ludwig van Beethovan
I wish that this noble statement were true for me as well, but that’s not often the case. When I try to be humble, I spare the details, often at great expense to the lesson. When I try to be overly showy, I don’t get to the point.
In just the past month alone, I have been hesitant to write out my thoughts, and have lost any possibility of pursuing those endeavors further, as I can no longer remember them. I failed to ask questions in fear of projecting uncertainty. What I have succeeded at doing is completely passing on the opportunity to reflect later on.
I don’t write because I don’t re-read. This post has already grown so long. Will I read it later? So let the lesson be this: Write often, write succinctly, and reflect.
Tags: beethovan, exploring, lesson, questions, reflect, thinking, writing
