vault backup: 2026-02-19 17:20:00

This commit is contained in:
2026-02-19 17:20:00 -05:00
parent e5b09261f6
commit cc352c4d51
100 changed files with 509 additions and 312 deletions
+38
View File
@@ -0,0 +1,38 @@
---
id: 2025-11-21T10:11:00-05:00
aliases: []
title: 2025-11-21 10:11:??
tags:
- authorship/original
- destiny/permanent
- status/complete
- topic/estimating
- type/timestamped
---
# 2025-11-21 10:11:??
#topic/organization
> [!quote] [ELECTRI's Industry Benchmarking Tool - ELECTRI International](https://www.electri.org/research-overview/electris-industry-benchmarking-tool/)
> ### Hours Burned vs. Hours Earned
>
> Definition:
> Comparison between portion of project estimated hours complete
> compared with the actual hours spent on the task.
> This is the labor performance factor
> (needs to reference the labor factor used at bid time for a full comparison).
This is a terribly problematic metric.
If a project went over its material budget
despite standard rigorous oversight
where would you first look,
construction or estimating?
In almost all cases the safer bet is estimating.
Why should labor be different?
Wherever there is budget variance
there is a persistent tendency to blame construction
before estimating.
[[purpose-of-construction-estimating#The Myth of Estimate Accuracy]]
+35
View File
@@ -0,0 +1,35 @@
---
id:
aliases: []
title: 2026-01-31 12:48:00
tags:
- authorship/original
- destiny/permanent
- status/draft
- type/timestamped
daily: "[[2026-01-31]]"
dg-publish: true
---
# 2026-01-31 12:48:00
Follow-up to [[2026-01-19#2026-01-19 11:57]]
a **natural-language parser**
could easily determine where hyphens should be replaced with em dashes.
"deep-set" `{ADJECTIVE}-{VERB_PAST_TENSE}` -> `{COMPOUND_ADJECTIVE}`
"leather-covered" `{NOUN}-{VERB_PAST_TENSE}` -> `{COMPOUND_ADJECTIVE}`
"magic-worker" `{NOUN}-{AGENT_NOUN}` -> `{COMPOUND_NOUN}`
"eon-old" `{NOUN}-{ADJECTIVE}` -> `{COMPOUND_ADJECTIVE}`
"one-armed" `{NUMBER_ADJECTIVE}-{ADJECTIVE}` -> `{COMPOUND_ADJECTIVE}`
"twenty-two" `{NUMBER_ADJECTIVE}-{NUMBER_ADJECTIVE}` -> `{NUMBER_ADJECTIVE}`
[Agent noun](https://en.wikipedia.org/wiki/Agent_noun)
* **-er / -or**: _worker, runner, actor_
* **-ist**: _pianist, socialist_
* **-ant / -ent**: _assistant, respondent_
[Theta role](https://en.wikipedia.org/wiki/Theta_role)
* **-ee** (often recipient rather than doer, but related): _employee, trainee_
+27
View File
@@ -0,0 +1,27 @@
---
id: 2026-01-31T17:49:00-05:00
aliases: []
title: 2026-01-31 17:49:00
tags:
- authorship/other
- destiny/permanent
- status/draft
- type/timestamped
daily: "[[2026-01-31]]"
dg-publish: true
---
# 2026-01-31 17:49:00
> [!quote] [Linux Bash Shell Script Error: cannot execute: required file not found - Unix Stack Exchange](https://unix.stackexchange.com/questions/721844/linux-bash-shell-script-error-cannot-execute-required-file-not-found)
>
> > [!quote] [ctrl-alt-delor](https://unix.stackexchange.com/users/4778/) 2022-10-21 08:16
> > Note: use of back ticks e.g. `... ``command`` ...` is deprecated. Use the newer easier to use `"$(command)"` (but yes this simple use with echo is hoop jumping). Use of `.sh` at the end of file names is not Unix. And it violates the principle of abstraction, as it leaks implementation detail. Just name them by what they do, not how they do it.
>
> > [!quote] [Kusalananda](https://unix.stackexchange.com/users/116858/) 2022-10-21 08:22
> > @ctrl-alt-delor They are most definitely not deprecated, only awkward to use and should be avoided. In this particular case, any type of command substitution would be inappropriate. As for naming files, that's really up to the user. If you are concerned with abstraction, you could suggest the user uses the `hostname` command directly rather than via a nonsensical script with a function.
>
> > [!quote] ctrl-alt-delor 2022-10-21 08:29
> > `deprecate` : express disapproval of. I disapprove. You say should be avoided. Thus deprecated. As for up to the user. I agree, it is the same for drug use. And the best abstraction is no abstraction (it depends). However I assume the examples were minimum non-working examples.
>
> > [!quote] [Ed Swangren](https://unix.stackexchange.com/users/597584/) 2024-09-28 07:46
> > @ctrl-alt-delor `deprecate(3):` to withdraw official support for or discourage the use of (something, such as a software product) in favor of a newer or better alternative" you're right, but only accidentally, so no credit given and mockery warranted. Citing a dictionary definition in a technical context is always wrong, citing the wrong one is lazy and stupid, and citing your opinion as evidence is in line with what I'd expect after #1 and #2. No one cares.
+62
View File
@@ -0,0 +1,62 @@
---
id:
aliases: []
title: 2026-02-02 06:50:00
tags:
- authorship/original
- destiny/permanent
- status/draft
- type/timestamped
- topic/meta
dg-publish: true
daily: "[[2026-02-02]]"
---
# 2026-02-02 06:50:00
I'm considering including management scripts in this vault,
but I'd generally prefer to keep it content only.
Ideally I could do anything I'd use a script for with a plugin,
but they have their limitations.
Eventually I should [[learn-to-write-obsidian-plugins]],
but for now here's a useful cmdlet I wrote a while ago but misplaced.
```powershell
function Import-Markdown {
[CmdletBinding()]
param(
[Parameter(Mandatory)]
[string]$Path
)
try {
$command = Get-Command ConvertFrom-Yaml -ErrorAction "Stop"
}
catch {
throw "no YAML conversion module installed. Try ``Install-Module powershell-yaml``."
}
$content = Get-Content -Path $Path -Raw
$pattern = [Regex]'(?ms)^---\s*(.*?)\s*---\s*(.*)$'
$match = $pattern.Match($content)
if ($match.Success) {
$frontmatter = $match.Groups[1].Value
$body = $match.Groups[2].Value
}
else {
$frontmatter = ''
$body = $content
}
return [pscustomobject]@{
frontmatter = $frontmatter | ConvertFrom-Yaml
body = $body
}
}
```
That match expression is bizarre,
and the whole thing needs better error handling,
but it works.
A `Where-Markdown` for filtering by tags
and a `{Verb}-Markdown` for modifying tags
would be idiomatic.
+49
View File
@@ -0,0 +1,49 @@
---
id:
aliases: []
title: 2026-02-02 12:18:00
tags:
- authorship/original
- destiny/permanent
- status/draft
- type/timestamped
- occupational/takeoff
dg-publish: true
daily: "[[2026-02-02]]"
---
# 2026-02-02 12:18:00
## Sleeving Takeoff Breakdown Direction
Updated [[sleeving-takeoff#Breakdowns]]
per clarification with Joel.
Previous direction below.
> * `Area` = "01 - Feeders/Risers ..."
> * `Phase` = "Feeders"
> * `System` = "FRR - Feeders and Risers"
>
> For all sleeving, regardless of application.
I feel certain I received this from someone I trust
because I've been doing it against my better judgement,
but either it wasn't Joel (Ben maybe?)
or he was referring to a different scenario
(which my notes no longer cover).
***
I asked Joel if he could think of any direction
that I might have misinterpreted
to get to that above,
but he said he could not.
***
I spoke with Willie about it,
he says he's always put sleeving in each relevant system.
I told him I knew it had to have been spoken
because I remember it being justified as WBS allocation thing,
but I think now Joel told me correctly at the time,
that is, gave me the same direction he gave me today,
I just somehow heard the complete opposite.
+20
View File
@@ -0,0 +1,20 @@
---
id:
aliases: []
title: 2026-02-03 08:34:00
tags:
- authorship/original
- destiny/permanent
- status/draft
- type/timestamped
- occupational
dg-publish: true
daily: "[[2026-02-03]]"
---
# 2026-02-03 08:34:00
Drawings bookmark colors
* Lighting: Yellow
* Power: Green
* Riser/One-Line: Light Blue
+20
View File
@@ -0,0 +1,20 @@
---
id:
aliases: []
title: 2026-02-03 15:04:00
tags:
- authorship/original
- destiny/permanent
- status/draft
- type/timestamped
- topic/estimating
dg-publish: true
daily: "[[2026-02-03]]"
---
# 2026-02-03 15:04:00
It is possible, even common,
to be _confident_ in an _uncertain_ estimate.
Confidence is a measure of the potential for an estimate to vary from reality,
but an estimate can (and _should_ where possible)
include respect for uncertainty.
+18
View File
@@ -0,0 +1,18 @@
---
id:
aliases: []
title: 2026-02-03 16:17:00
tags:
- authorship/original
- destiny/permanent
- status/draft
- type/timestamped
- occupational
dg-publish: true
daily: "[[2026-02-03]]"
---
# 2026-02-03 16:17:00
Valued in [[pdi-estimating#Construction Estimating (ConEst)|ConEst]] estimators:
* **consistency**
* **humility** --- willingness to say "I don't know that, please teach me"
+95
View File
@@ -0,0 +1,95 @@
---
id:
aliases: []
title: 2026-02-04 08:07:00
tags:
- authorship/original
- destiny/permanent
- status/draft
- type/timestamped
- occupational
dg-publish: true
daily: "[[2026-02-04]]"
---
# 2026-02-04 08:07:00
## Questions for ConEst
### Purpose of ConEst
What is the purpose of ConEst?
To comb for requirements Bid missed?
To create the CBOM for Ops?
Anything else?
How do they rank in importance?
Why are other departments so confused about ConEst's purpose?
(Ops stakeholder auditing CBOM to Joel: "missing screws")
If we don't know, and Ops doesn't know, who does?
That is, who defines our purpose?
### ConEst Organization
What freedom does ConEst have to change its process and deliverables?
Suppose a plan to have Bid, with their request for ConEst,
articulate certain requirements which they must have possessed to produce the bid estimate.
Who would be involved in the change?
Who would be the one to deny the request?
If Bid's proposals are audited,
why do they still cause ConEst constant headache?
("local lighting control")
***
Estimators and seniors are biased towards imprecision
because its tolerance reduces monotonous work,
but the logical conclusion of such bias is a Bid estimate.
Obviously there is an ideal compromise
between 1:1 takeoff to install and a square foot budget
that ConEst is intended to produce.
Who is ultimately responsible
for defining the position of that point on the spectrum?
How is it defined?
How is it expected to be communicated to seniors and estimators?
#### Process Variation
What is an acceptable level of process variance senior to senior?
To my mind the answer ought to be "none"
or at least "as little as possible",
since our process benefits greatly
from every bit of consistency we can maintain,
saying nothing of the fact that there usually _is_
a better option between two.
What's being done to address the variance which exists?
What's being done to prevent it from re-emerging?
It is my belief that the most practical solution
is the frequent rotation of estimators in senior teams.
It is in the interest of estimators
that their personal heuristics not depend on who they're working for,
so they can be expected to call attention to inconsistency
allowing it to be addressed permanently.
The only other option I can imagine
is to document exact procedures for every scenario,
which is obviously foolhardy.
### Less Important
#### Proposal Transparency
Am I alone in feeling that our proposals are deceptive
beyond reasonable explanation?
Would I be better of keeping my mouth shut about it?
#### Incentives
Bonuses based on awarded profit
incentivize problematic behavior
([[game-theory#Stag Hunt|hare-hunting]]).
Has such behavior been observed,
or has chief strategy been organization-aligned
in spite of the incentive?
+51
View File
@@ -0,0 +1,51 @@
---
id:
aliases: []
title: 2026-02-04 09:00:00
tags:
- authorship/original
- destiny/permanent
- status/draft
- type/timestamped
- topic/organization
dg-publish: true
daily: "[[2026-02-04]]"
---
# 2026-02-04 09:00:00
%%
Exact time of writing unknown.
Between [[2026-02-04_08-07-00]] and [[2026-02-04_13-42-00]]
%%
## T-Shirt Sizing
"T-shirt sizing" or "T-shirt size estimation"
is a method of project estimation
characterized by the use of T-shirt sizes
representing project scale buckets.
> [!example] [T-Shirt Sizing in Agile --- Project Management Pathways](https://www.projectmanagementpathways.com/project-management-articles/tshirt-sizing-in-agile-projects)
> * **XS (1-2 days):** Simple UI changes or minor bug fixes
>
> Example: "Update button color on checkout page"
>
> * **S (2-3 days):** Feature enhancements with minimal complexity
>
> Example: "Add product sorting by price"
>
> * **M (5-7 days):** Features requiring moderate integration
>
> Example: "Implement basic search filters"
>
> * **L (8-10 days):** Complex features affecting multiple components
>
> Example: "Create shopping cart functionality"
>
> * **XL (2+ weeks):** Major features requiring breaking down
>
> Example: "Implement payment gateway integration"
The buckets chosen should be wide enough
that scale can be confidently estimated
after minimal investigation.
+26
View File
@@ -0,0 +1,26 @@
---
id:
aliases: []
title: 2026-02-04 13:42:00
tags:
- authorship/original
- destiny/permanent
- status/draft
- type/timestamped
- occupational/takeoff
dg-publish: true
daily: "[[2026-02-04]]"
---
# 2026-02-04 13:42:00
[[fire-alarm-takeoff]]
> [!quote] Art Baldwin 2026-02-04 (pp.)
> Fire, smoke, and combination fire/smoke dampers
> may require 120V power, and thus electrical takeoff,
> or only 24V, in which case mechanical will own the scope.
> Assuming 120V is a budget-conservative estimating convenience,
> which is generally considered acceptable
> in lieu of determining specified requirements,
> but further investigation may be expected
> if more than a few per floor are shown.
+34
View File
@@ -0,0 +1,34 @@
---
id:
aliases: []
title: 2026-02-04 17:02:00
tags:
- authorship/original
- destiny/permanent
- status/draft
- type/timestamped
- occupational/takeoff
dg-publish: true
daily: "[[2026-02-04]]"
---
# 2026-02-04 17:02:00
While observing takeoff for
[[electrical-takeoff#Unit Condensing Units|unit condensing units]],
the project engineer expressed confusion
at the process of calculating average horizontal length,
expressing that it was more complicated than they expected
considering takeoff procedure for similar processes.
The PE asked why we would not simply use the maximum
so that we would not risk having too little overall.
Their expectation surprised me,
since it is intuitive to me
that there must be some limit to the logic of "covering it",
since it is always within our power to add contingency,
and especially because---if anything---
I feel that our procedures tend towards
the upper end of reasonable ECI.
(see [[value-of-information.jpg]])
My response was not well formulated.
+21
View File
@@ -0,0 +1,21 @@
---
id:
aliases: []
title: 2026-02-04 18:05:00
tags:
- authorship/original
- destiny/permanent
- status/draft
- type/timestamped
- topic/estimating
dg-publish: true
daily: "[[2026-02-04]]"
---
# 2026-02-04 18:05:00
Expected value of sample information (EVSI)
must define acceptable takeoff.
If not, we are---by definition---
throwing money away
in the form of wasted estimator hours
and missed bid opportunities.
+38
View File
@@ -0,0 +1,38 @@
---
id:
aliases: []
title: 2026-02-04 19:35:00
tags:
- authorship/original
- destiny/permanent
- status/draft
- type/timestamped
dg-publish: true
daily: "[[2026-02-04]]"
---
# 2026-02-04 19:35:00
## Time Interval Conversion
In [[2026-01-09#2026-01-09 12:00]]
I defined time intervals according to averages
which are true of the Gregorian calendar for $\lim\limits_{t\to\infty}$,
but which are not so appropriate for a human lifetime scale.
True of the Gregorian calendar (and its predecessors)
for all time scales:
$$
\begin{align*}
1~\text{Year} &\equiv 12~\text{Months} \\
1~\text{Week} &\equiv 7~\text{Days}
\end{align*}
$$
In 2001--2099 leap years occur exactly once in four years.
$$
\begin{align*}
1~\text{Year} &= 365.25~\text{Days} \\
\end{align*}
$$
+19
View File
@@ -0,0 +1,19 @@
---
id:
aliases: []
title: 2026-02-05 06:20:00
tags:
- authorship/original
- destiny/permanent
- status/draft
- type/timestamped
dg-publish: true
daily: "[[2026-02-05]]"
---
# 2026-02-05 06:20:00
I believe I have improved significantly
in my ability to explain myself verbally
in the past few months,
and since I am my own worst critic
there must be some truth there.
+100
View File
@@ -0,0 +1,100 @@
---
id:
aliases: []
title: 2026-02-05 10:14:01
tags:
- authorship/original
- destiny/permanent
- status/draft
- type/timestamped
- occupational/takeoff
dg-publish: true
daily: "[[2026-02-05]]"
weekly: "[[2026-W06]]"
monthly: "[[2026-02]]"
quarterly: "[[2026-Q1]]"
yearly: "[[2026]]"
---
# 2026-02-05 10:14:01
## Mechanical Connection Selection
Relevant to [[electrical-takeoff]],
sourced from Joel Jansen's OneNote Takeoff Notes "Mechanical Connections".
Ben says he has never used any PVC assembly except .../`PVC - ...`.
### NM Connections
* .../`NM CABLE ASSEMBLIES`
Type III, IV, and V construction.
Usually only 6 AWG and smaller;
EMT is expected to be cheaper for larger sizes.
### MC Connections
* .../`MC CABLE ASSEMBLIES`
Type I and II construction.
> [!quote] Paraphrased from Source
> Usually only short runs,
> otherwise use PVC if possible.
> [!important]
> Note that MC cable may be forbidden for this application.
> > [!quote] Hampton Roads Navy UH - Newport News, Project Specifications
> > MC cable shall not be allowed for wiring to mechanical equipment
> > except for within the dwelling units.
### EMT Connections
* .../`EMT SS - ...`
* .../`EMT COMP - ...`
May be preferred for equipment in the same electrical room
as the panel feeding it,
otherwise treat as last resort,
preferring MC or PVC.
### PVC Connections
* .../`PVC - ...`
Use where equipment disconnect is not integral.
* .../`PVC - ... - PVC CEILING BOX`
J-box in the ceiling for mechanical connections,
or where a motor-rated switch is shown.
* .../`PVC - ... - STL BOX & EXT RING`
Use for equipment powered from a wall mount j-box
* .../`PVC - ... - EMT DROP`
> Assembly Note: Does not include j-box
Use in lieu of .../`PVC - ...`
where drop would be exposed
if PVC is not permitted to be exposed.
> Also use for J-Boxes for Heaters.
> [!example]
> directional unit heater shown with connection to a flush wall mount j-box
* .../`PVC - ... - EMT RISE`
> Assembly Note: Does not include j-box
> Use if panels are located on level below panel.
> EMT covers vertical transition for exposed conduit
* .../`PVC - MECH CONNECTION - SGL REC`
* .../`PVC - STL BOX W/ EXT RING & COVER`
> For garage heaters, no labor/power term
+24
View File
@@ -0,0 +1,24 @@
---
id:
aliases: []
title: 2026-02-05 12:14:47
tags:
- authorship/original
- destiny/permanent
- status/draft
- type/timestamped
- topic/construction/electrical
dg-publish: true
daily: "[[2026-02-05]]"
weekly: "[[2026-W06]]"
monthly: "[[2026-02]]"
quarterly: "[[2026-Q1]]"
yearly: "[[2026]]"
---
# 2026-02-05 12:14:47
NM and SE cable are never permitted in Type III, IV, or IV construction.
[[nfpa-70_338_se-cable#338.10(B)(4) Installation Methods for Branch Circuits and Feeders.|338.10(B)(4)(a)(1)]]
[[nfpa-70_334_nm-cable#334.12(A) Types NM and NMC.|334.12(A)(1)]]
+24
View File
@@ -0,0 +1,24 @@
---
id:
aliases: []
title: 2026-02-05 16:50:34
tags:
- authorship/original
- destiny/permanent
- status/draft
- type/timestamped
dg-publish: true
daily: "[[2026-02-05]]"
monthly: "[[2026-02]]"
quarterly: "[[2026-Q1]]"
weekly: "[[2026-W06]]"
yearly: "[[2026]]"
---
# 2026-02-05 16:50:34
[[how-to-measure-anything-in-project-management]]
makes some bizarre choices in terminology.
"Cost of Information" is not a widely used term,
but Hubbard et al. treat it as a household name.
[Weight of Evidence (WOE) and Information Value (IV) Explained](https://www.listendata.com/2015/03/weight-of-evidence-woe-and-information.html)
+25
View File
@@ -0,0 +1,25 @@
---
id:
aliases: []
title: 2026-02-07 09:16:31
tags:
- authorship/original
- destiny/permanent
- status/draft
- type/timestamped
- topic/hobbies/reading
dg-publish: true
daily: "[[2026-02-07]]"
weekly: "[[2026-W06]]"
monthly: "[[2026-02]]"
quarterly: "[[2026-Q1]]"
yearly: "[[2026]]"
---
# 2026-02-07 09:16:31
> [!quote] Malcolm X on Prospects for Freedom in 1965 (January 7, 1965)
> You can't separate peace from freedom
> because no one can be at peace unless he has his freedom.
> [!quote] Patera Silk in _Exodus from the Long Sun_ (1996), by Gene Wolfe
> Nobody can be truly free without peace.
+70
View File
@@ -0,0 +1,70 @@
---
id:
aliases: []
title: 2026-02-08 08:00:49
tags:
- authorship/original
- destiny/permanent
- status/draft
- type/timestamped
- topic/hobbies/reading
dg-publish: true
daily: "[[2026-02-08]]"
weekly: "[[2026-W06]]"
monthly: "[[2026-02]]"
quarterly: "[[2026-Q1]]"
yearly: "[[2026]]"
---
# 2026-02-08 08:00:49
> [!danger] Spoiler Alert
> This note contains major spoilers
> for _Red Rising_ by Pierce Brown.
I started _Red Rising_ yesterday
at the recommendation of three coworkers.
Within the first hundred pages
the protagonist's wife is introduced,
given the most sympathetic characterization possible,
then summarily killed to motivate him to action.
This is an example of [fridging](https://en.wikipedia.org/wiki/Women_in_refrigerators),
a misogynist trope of lazy writing.
Darrow takes Eo's death _far_ too gracefully,
he doesn't mourn, he gets straight to action.
He's characterized as hard,
(he doesn't cry at his father's execution, either)
but his immediate acceptance is so callous
it legitimately makes me sick.
There are ways this could be recovered,
especially if Darrow recognizes
the emotions he's been bottling up,
or that there's no way Eo would approve of his methods.
(He flirts with the second
but doesn't give a hint that it might change his actions)
I am very dubious that the series will go that direction though.
It seems more interested in being "fuck this dystopia"
than in criticizing the male power fantasy roots
that often underly such motivations.
I am also _so_ tired of dystopian settings with caste systems
that are begging for a Buzzfeed "Which Caste Are You?" test.
It's a cruel world that _Hunger Games_ is the best the genre has to offer.
> [!aside] Digression
> If Suzanne Collins was unpopular online
> people would be doing the thing they do with Harry Potter now,
> where they point out bad writing (and there's no shortage)
> that always existed but that they only have a problem with now.
This book is almost too YA for me to bare.
Were I compelled to say something positive about the book,
I enjoy that the narration is in present tense.
I think it works well to invest the reader in the story,
(I was able to read thirteen chapters in one sitting)
and it's fun for its rarity besides.
%% EOF 2026-02-08 09:02 %%
+32
View File
@@ -0,0 +1,32 @@
---
id:
aliases: []
title: 2026-02-09 12:42:11
tags:
- authorship/original
- destiny/permanent
- status/draft
- type/timestamped
daily: "[[2026-02-09]]"
dg-publish: true
monthly: "[[2026-02]]"
quarterly: "[[2026-Q1]]"
weekly: "[[2026-W07]]"
yearly: "[[2026]]"
---
# 2026-02-09 12:42:11
> [!quote] [[kahneman_2011_thinking#5. Cognitive Ease]]
>
> ```mermaid
> flowchart LR
> in1["REPEATED EXPERIENCE"] --> ease["EASE"]
> in2["CLEAR DISPLAY"] --> ease
> in3["PRIMED IDEA"] --> ease
> in4["GOOD MOOD"] --> ease
> ease --> out1["FEELS FAMILIAR"]
> ease --> out2["FEELS TRUE"]
> ease --> out3["FEELS GOOD"]
> ease --> out4["FEELS EFFORTLESS"]
> ```
> **Figure 5. Causes and Consequences of Cognitive Ease**
+27
View File
@@ -0,0 +1,27 @@
---
id:
aliases: []
title: "2026-02-10 07:44:29"
tags:
- authorship/original
- destiny/permanent
- status/draft
- type/timestamped
dg-publish: true
daily: "[[2026-02-10]]"
weekly: "[[2026-W07]]"
monthly: "[[2026-02]]"
quarterly: "[[2026-Q1]]"
yearly: "[[2026]]"
---
# 2026-02-10 07:44:29
## HTML/MD/EPUB Cleanup
```powershell
$newText = $text -replace '\n+<div[^>]+>[\n\s]+</div>\n+', "`n`n"
```
```powershell
$newText = $text -replace '\n+<span[^>]+>[\n\s]*</span>\n+', "`n`n"
```
+23
View File
@@ -0,0 +1,23 @@
---
id:
aliases: []
title: "2026-02-10 07:47:33"
tags:
- authorship/original
- destiny/permanent
- status/draft
- type/timestamped
dg-publish: true
daily: "[[2026-02-10]]"
weekly: "[[2026-W07]]"
monthly: "[[2026-02]]"
quarterly: "[[2026-Q1]]"
yearly: "[[2026]]"
---
# 2026-02-10 07:47:33
## Filter VSCode CSpell Problems
```powershell
Get-Clipboard | ConvertFrom-Json | Where-Object owner -EQ cSpell | Select-Object -ExpandProperty message | Sort-Object -Unique | ForEach-Object { $_ -replace '"(.+?)": .+', "`$1" } | Set-Clipboard
```
+81
View File
@@ -0,0 +1,81 @@
---
id:
aliases: []
title: 2026-02-10 15:49:04
tags:
- authorship/original
- destiny/permanent
- occupational
- status/draft
- type/minutes
- type/timestamped
daily: "[[2026-02-10]]"
dg-publish: true
monthly: "[[2026-02]]"
quarterly: "[[2026-Q1]]"
weekly: "[[2026-W07]]"
yearly: "[[2026]]"
---
# 2026-02-10 15:49:04
## Hampton Roads Navy - Norfolk: Director Review
### Dramatis Personae
Director of ConEst: Corwin Fluit
Bid Estimator: Christian Pereiro
Senior ConEst Estimator: Joel Jansen
### Lighting Control
* Corridors: $10 per linear foot
* Amenity: $5 per square foot
> Digital lighting control is required
> * FALSE: Multiple occupancy sensors per zone necessitates digital control.
> * FALSE: 0-10V dimming necessitates digital control.
> * FALSE: 0-10V dimming + occupancy sensing necessitates digital control.
> * TRUE: 0-10V dimming controlled by occupancy sensing necessitates digital control.
Systems refused to quote lighting control due to lack of detail,
but sufficient detail was provided.
Bid expected takeoff to include DLM devices and cabling.
### Closeout
On Base - Newport News is not
Carried labor for lost time due to badging
#### Equipment
> [!quote] Corwin Fluit 2026-02-10
> `AUGER ON BOBCAT (per pole)` does not include cost for setting pole
### Free Notes
Ops creates, approves the labor plan.
This limits our ability to make interesting decisions:
MC cable ILO PVC in-slab pushes the schedule out.
[[estimating-golf]] question, asked by Corwin:
"Are the electric rooms stacked?"
### Thoughts
#### Corwin
Corwin is a true _estimator_.
I've met few people more willing to make calculations
and give confident estimates in conversation.
He understands the necessity of accepting and accounting for risk.
He is as critical of overly-heavy estimates
as light estimates.
He specifically prefers accurate line item costs
with a single contingency
over inflated individual budgets.
+232
View File
@@ -0,0 +1,232 @@
---
id: 2026-02-11T12:12:16-05:00
aliases: []
title: 2026-02-11 12:12:16
tags:
- authorship/original
- destiny/permanent
- status/draft
- type/timestamped
daily: "[[2026-02-11]]"
dg-publish: true
monthly: "[[2026-02]]"
quarterly: "[[2026-Q1]]"
weekly: "[[2026-W07]]"
yearly: "[[2026]]"
---
# 2026-02-11 12:12:16
Hello Team,
Below is a comprehensive list of means & methods for **1990 K Street**.
Please confirm you have received this email
and respond with any questions or comments.
* **Takeoff Request Stage:** Full Takeoff
%% Stage 1, Stage 1 + Units, Full takeoff %%
* **Delivery Method:** Plans & Specs
%% Plans & Specs, Design Build, Design Assist, P&S with Approved VE %%
* **Document Stage:** Permit
%% DD, CD, Permit, GMP, Bid, Awarded %%
* **Drawings Date:** 2025-12-05
* **Project Manual Date:** 2025-12-05
* **Proposal Date:** 2026-01-22
### Project Specification Callouts
%% Put page of Drawing or PM after answer %%
* **Conduit:**
* EMT Fittings: Set-screw _---Spec 260533.13 (p. 1423)_
%% GRC, coupling specs, etc. %%
* **Wire:**
* Material: Aluminum 100A and larger _---E021 "ALUMINUM FEEDER SCHEDULE" Note 1(b)_
* Acceptable Manufacturers: _---Spec 260519 (p. 1384)_
* Alpha Wire; Brand of Belden, Inc.
* Belden Inc.
* Cerro Wire LLC
* Encore Wire Corporation
* General Cable; Prysmian Group North America
* Okonite Company
* Service Wire Co.
* Southwire Company, LLC
* WESCO
* **MC Cable:**
* Application: Concealed feeders and branch circuits _---Spec 260519 (p. 1389)_
%% Branch homeruns only; Not permitted %%
* Acceptable Manufacturers: _---Spec 260519 (p. 1385-1386)_
* AFC Cable Systems; Atkore International
* Alpha Wire; Brand of Belden, Inc.
* Belden Inc.
* Cerro Wire LLC
* Encore Wire Corporation
* General Cable; Prysmian Group North America
* Okonite Company
* Southwire Company, LLC
* WESCO
* ==Conductors: Copper _---Spec 260519 (p. 1386)_==
* ==Armor: Steel _---Spec 260519 (p. 1386)_==
* ==Jacket: PVC _---Spec 260519 (p. 1386)_==
* **Steel Box Depth:**
* Telecom: 2-1/8" _---Spec 270500 (p. 1673)_
* Security: 2-1/8" _---Spec 280500 (p. 1753)_
* Other Applications: Not specified
%% 1-1/2", 2-1/8" %%
* **Floor Boxes:** Sheet metal with brass or aluminum covers _---Spec 262719 (p. 1541)_
* **Wiring Devices:**
* Units:
* Current rating: Unspecified. Assuming 15A for takeoff.
* Standard/Decora: Unspecified. Assuming Toggle/Duplex for takeoff.
%% 15A Decora %%
* BOH/Common Areas:
* Current rating: Unspecified. Assuming 20A for takeoff.
* Standard/Decora: Unspecified. Assuming Toggle/Duplex for takeoff.
%% 20A Toggle/Duplex %%
* **Switchboards:**
* Acceptable Manufacturers: _---Spec 262413 (p. 1502)_
* ABB, Electrification Business
* Eaton
* Siemens Industry, Inc., Energy Management Division
* Square D; Schneider Electric USA
* General Electric
* Bus Material: Aluminum _---Spec 262413 (p. 1503)_
* Interrupting Current Rating: Not specified.
* **Distribution Panelboards:**
* Acceptable Manufacturers: _---Spec 262413 (p. 1514-1515)_
* Eaton
* Bus Material: Aluminum _---Spec 262413 (p. 1513)_
* Breaker Types: Bolt-on _---Spec 262413 (p. 1515)_
%% Snap-on, bolt on %%
* Interrupting Current Rating: Not specified.
* **Load Centers:**
* Acceptable Manufacturers: _---Spec 262413 (p. 1514-1515)_
* ABB, Electrification Business
* Eaton
* Siemens Industry, Inc., Energy Management Division
* Square D; Schneider Electric USA
* Bus Material: Aluminum _---Spec 262413 (p. 1513)_
* Breaker Types: Plug-in _---Spec 262413 (p. 1515)_
%% Snap-on, bolt on %%
* Interrupting Current Rating: Not specified.
* ==Covers shall be factory-applied white paint.== _---Dwg. E401-E405 "ELECTRICAL DRAWING NOTES" (P)_
* **Transformers:**
* Winding Material: Aluminum _---Spec 262213 (p. 1495)_
* K-Rating: Not specified.
%% Windings AL or CU, K-rating %%
* **Generator:** (1) 600kW Diesel
* Enclosure Specs: Level 2 Sound Attenuating Weatherproof Enclosure _---Dwg. E014_
* Remote Tank: None shown or specified.
* Tank Size: 24hrs at 100% load _---Spec 263213.13 (p. 1604)_
* Load Banks: Internal, 50% load _---Dwg. E014, Spec 263213.13 (p. 1608)_
* Acceptable Manufacturers: _---Spec 263213.13 (p. 1600)_
* Caterpillar, Inc.; Electric Power Division
* Cummins Power Generation
* Generac
* Hipower Systems
* Kohler Power Systems
* Rolls-Royce Solutions America Inc
### Project Drawing/Detail Callouts
Dwg. IDS-01A "OUTLET SPECIFICATIONS": Screwless Cover
Dwg. IDS-01A "SWITCHING SPECIFICATIONS": Legrand Tru-Universal Rocker/Dimmers
(Is this for Amenity/Common Areas?)
<!--
* **Describe conflicts between drawings / proposal**
%% Plans show CU feeders, proposal calls for aluminum; Specification grade devices, etc. %%
* **Cost drivers in details not shown elsewhere on plans**
%% Assuming this refers to lighting control %%
-->
### PDI System Execution Plan
* **Primaries:** Conduit and wiring excluded. _---Proposal 2026-01-22, Ex. B, Exclusions, Line 27_
%% Installation only, (9) 6" PVC %%
* **Secondaries:**
* Schedule 40 PVC UG; _---Proposal 2026-01-22, Ex. B, Inclusions Line 54-55_
* wiring excluded. _---Proposal 2026-01-22, Ex. B, Exclusions, Line 28_
%% PVC UG, GRC Stub-ups, AL %%
* **Feeders:** PVC UG, EMT OH; AL 100A and larger; 2% voltage drop.
%% PVC UG, EMT OH, AL over 100A, 2% VD %%
%% Emergency Feeds MI Cable %%
* **Unit Subfeeds:** MC OH; size per E025-E028 meter bank schedules; 3% voltage drop.
%% MC OH AL, VD per Chart on E5.01 %%
* **Units:**
* DW/Disposal - Separate Circuit
* Range - \#6/3
* Kitchen Backsplash - Decora (Non-Combo Small Appliance Breakers)
* 120V Smokes
* EWH - \#8/2
* VRF HVAC
* 20A Toggle Switches
* 15A Duplex Receptacles
%% 15A Decora, Disposals, T-stat, Floor Boxes, Shade Control, Doorbells, Dimmer Switches, etc. %%
* **Telecom:**
* 30" MSDE; _---T0.32/1 Note 3: "PRIMEX SOHOPRO P3000ND"_
* (1) 1" innerduct to IDF. _---Proposal 2026-01-22, Ex. B, General Requirements, Line 114_
%% 42" MSDE, No Cable Homeruns, (1) 1" Back to IDF, CAT6 with Stub-ups %%
* **EV Chargers:** (2) dual circuit chargers with conduit, wire, data rough-in, and equipment.
%% (42) Conduit only, (56) Conduit & Wire, (20) Conduit, Wire & Equipment %%
* **Fire Alarm:** Devices PVC in-slab, Risers EMT.
%% Free-air where allowed by code. EMT Risers. %%
* **DAS:** System per PDI DAS Design.
%% Conduit only, Per PDI DAS Design %%
* **Low Voltage:** Free-air where allowed by code.
%% Free-air where allowed by code. Stub-ups to accessible ceilings. %%
### Lighting Control
* **Basis of Takeoff:** Design per Plans and Specs _---Christian Pereiro 2026-02-11_
%% Code Minimum per Energy Code Assigned, P&S, PDI Design %%
* **Area:** _---Dwg. E021 "AUTOMATED LIGHTING CONTROL - SEQUENCES OF OPERATIONS"_
* BOH: Line Voltage Control, no dimming
* Corridor: Digital Standalone Control, 0-10V dimming
* Amenity: Digital Standalone Control, 0-10V dimming
* Offices: Digital Standalone Control, 0-10V dimming, controlled receptacles as shown
* Site/Landscape: Line Voltage Control, no dimming
* Garage: Digital Standalone Control, 0-10V dimming
%% Assign Method to Areas: Line Voltage, Low-Voltage Stand Alone or Centralized System %%
Takeoff will utilize assemblies including
conduit rough-in, Cat5e cable, and device labor.
### Tasks/Quotes Needed for WBS
%% Delete any completed %%
%% * Electrical Constructability Review %%
%% * Electrical VDC %%
* Coordination Study
%% * DAS Public Safety Raceway Design %%
<!--
DAS Public Safety Raceway Design is necessary
if we own DAS pathways but not the system,
since if we own the system,
the raceway design will be included in the Systems quote.
-->
Thank you,
+41
View File
@@ -0,0 +1,41 @@
---
id: 2026-02-12T09:49:56-05:00
aliases: []
title: 2026-02-12 09:49:56
tags:
- authorship/original
- destiny/permanent
- status/draft
- type/timestamped
- topic/construction/electrical
daily: "[[2026-02-12]]"
dg-publish: true
monthly: "[[2026-02]]"
quarterly: "[[2026-Q1]]"
weekly: "[[2026-W07]]"
yearly: "[[2026]]"
---
# 2026-02-12 09:49:56
### Interrupting Rating
* "short-circuit interrupting rating"
Applies to "Equipment intended to interrupt current".
[[nfpa-70_110_requirements#110.9 Interrupting Rating.|NEC 110.9 Interrupting Rating.]]
Maximum current that the equipment can interrupt without damage.
Measured in amperes, usually shown as kAIC.
### Short-Circuit Current Rating (SCCR)
* "withstand rating"
[[nfpa-70_110_requirements#110.10 Circuit Impedance, Short-Circuit Current Ratings, and Other Characteristics.|NEC 110.10 Circuit Impedance, Short-Circuit Current Ratings, and Other Characteristics.]]
Applies to **assemblies**: distribution equipment like switchboards, panelboards, switches, etc.
Maximum current that the equipment can withstand
in a short-circuit event without damage.
Measured in amperes, usually shown as kA.
+24
View File
@@ -0,0 +1,24 @@
---
id: 2026-02-17T13-13-06-05:00
aliases: []
title: "2026-02-17 13:13:06"
tags:
- authorship/original
- destiny/permanent
- status/draft
- type/timestamped
dg-publish: true
daily: "[[2026-02-17]]"
weekly: "[[2026-W08]]"
monthly: "[[2026-02]]"
quarterly: "[[2026-Q1]]"
yearly: "[[2026]]"
---
# 2026-02-17 13:13:06
Relevant to [[2025-11-21_10-11-00#2025-11-21 10:11:??|2025-11-21 10:11:??]]
Today I spoke to a peer about
[[earned-value-management#Earned Value Management|earned value management]]:
how it relates to our [[pdi-estimating#ConEst Processes|WBS]]
and my negative opinion of it.
+44
View File
@@ -0,0 +1,44 @@
---
id: 2026-02-17T16-47-46-05:00
aliases: []
title: "2026-02-17 16:47:46"
tags:
- authorship/original
- destiny/permanent
- status/draft
- type/timestamped
dg-publish: true
daily: "[[2026-02-17]]"
weekly: "[[2026-W08]]"
monthly: "[[2026-02]]"
quarterly: "[[2026-Q1]]"
yearly: "[[2026]]"
---
# 2026-02-17 16:47:46
## The Lindy Effect
> [!quote] [Lindy effect - Wikipedia](https://en.wikipedia.org/wiki/Lindy_effect)
> The Lindy effect (also known as Lindy's law)
> is a theorized phenomenon by which the future life expectancy
> of some non-perishable thing,
> like a technology or an idea,
> is proportional to its current age.
> Thus, the Lindy effect proposes
> the longer a period something has survived
> to exist or be used in the present,
> the longer its remaining life expectancy.
> Longevity implies a resistance to change,
> obsolescence, or competition,
> and greater odds of continued existence into the future.
> Where the Lindy effect applies,
> mortality rate decreases with time.
>
> ...
>
> The concept is named after Lindy's delicatessen in New York City,
> where the concept was informally theorized by comedians:
> a show running only 2 weeks
> would be expected to last another 2 weeks,
> while a show that has lasted 2 years
> could expect a further 2-year run.