srp   422

« earlier    

Eversource Seeks To Reopen Record on Seacoast Reliability Project - InDepthNH.orgInDepthNH.org
Eversource wants to reopen the record on the 12.9-mile high-voltage transmission line – or Seacoast Reliability Project – to provide information on potentially impacted historic and scenic resources.
InDepthNH  SRP  sec 
4 days ago by eversourcenh
To the Editor: ‘Southern Pass’ is unnecessary - News - fosters.com - Dover, NH
I would like to add my voice to the near-unanimous chorus of opposition to Eversource’s “Southern Pass” transmission-line project, whose official name is the “Seacoast Reliability Project.” That was a well-chosen name: who can be against “reliability,” after all? That name also plays to our recent memories of the almost yearly power outages we New Englanders have suffered over the past several years. Those power outages were for the most part not caused by the failure of the major regional transmission lines, however. They were primarily caused by the failure of local distribution lines. The vast majority of our local distribution network consists of overhead power lines which are vulnerable to damage from ice and high winds.
fosters  letter  SRP  opponent 
26 days ago by eversourcenh
Repeat yourself, do more than one thing, and do more than one thing — programming is terrible
If you ask a programmer for advice—a terrible idea—they might tell you something like the following: Don’t repeat yourself. Programs should do one thing and one thing well. Never rewrite your code from scratch, ever!.

Following “Don’t Repeat Yourself” might lead you to a function with four boolean flags, and a matrix of behaviours to carefully navigate when changing the code. Splitting things up into simple units can lead to awkward composition and struggling to coordinate cross cutting changes. Avoiding rewrites means they’re often left so late that they have no chance of succeeding.

The advice isn’t inherently bad—although there is good intent, following it to the letter can create more problems than it promises to solve.

Sometimes the best way to follow an adage is to do the exact opposite: embrace feature switches and constantly rewrite your code, pull things together to make coordination between them easier to manage, and repeat yourself to avoid implementing everything in one function..



Repeat yourself, but don’t repeat other people’s hard work. Repeat yourself: duplicate to find the right abstraction first, then deduplicate to implement it.

With “Don’t Repeat Yourself”, some insist that it isn’t about avoiding duplication of code, but about avoiding duplication of functionality or duplication of responsibility. This is more popularly known as the “Single Responsibility Principle”, and it’s just as easily mishandled.



Gather responsibilities to simplify interactions between them

The only real difference between pushing something together and pulling something apart is that some changes become easier to perform than others.

The choice between a monolith and microservices is another example of this—the choice between developing and deploying a single service, or composing things out of smaller, independently developed services.

The big difference between them is that cross-cutting change is easier in one, and local changes are easier in the other. Which one works best for a team often depends more on environmental factors than on the specific changes being made.

Although a monolith can be painful when new features need to be added and microservices can be painful when co-ordination is required, a monolith can run smoothly with feature flags and short lived branches and microservices work well when deployment is easy and heavily automated.



Modularity is more than reducing things to their smallest parts.

A layer of small components with no shared features creates a need for a layer above where these features overlap, and if absent, the user will create one, with bash aliases, scripts, or even spreadsheets to copy-paste from.

Even adding this layer might not help you: git already has a notion of user-facing and automation-facing commands, and the UI is still a mess. It’s always easier to add a new flag to an existing command than to it is to duplicate it and maintain it in parallel.

Similarly, functions gain boolean flags and classes gain new methods as the needs of the codebase change. In trying to avoid duplication and keep code together, we end up entangling things.

Although components can be created with a single responsibility, over time their responsibilities will change and interact in new and unexpected ways. What a module is currently responsible for within a system does not necessarily correlate to how it will grow.



Modularity is about limiting the options for growth

A given module often gets changed because it is the easiest module to change, rather than the best place for the change to be made. In the end, what defines a module is what pieces of the system it will never responsible for, rather what it is currently responsible for.



This means recognizing which bits are slightly more entangled than others, knowing which pieces need to talk to each other, which need to share resources, what shares responsibilities, and most importantly, what external constraints are in place and which way they are moving.

In the end, it’s about optimizing for those changes—and this is rarely achieved by aiming for reusable code, as sometimes handling changes means rewriting everything.



Rewrite Everything

The reason rewrites are so risky in practice is that replacing one working system with another is rarely an overnight change. We rarely understand what the previous system did—many of its properties are accidental in nature. Documentation is scarce, tests are ornamental, and interfaces are organic in nature, stubbornly locking behaviors in place.

If migrating to the replacement depends on switching over everything at once, make sure you’ve booked a holiday during the transition, well in advance.

Successful rewrites plan for migration to and from the old system, plan to ease in the existing load, and plan to handle things being in one or both places at once. Both systems are continuously maintained until one of them can be decommissioned. A slow, careful migration is the only option that reliably works on larger systems.



The reason we say “Never Rewrite Code” is that we leave rewrites too late, demand too much, and expect them to work immediately. It’s more important to never rewrite in a hurry than to never rewrite at all.



null is true, everything is permitted

The problem with following advice to the letter is that it rarely works in practice. The problem with following it at all costs is that eventually we cannot afford to do so.

It isn’t “Don’t Repeat Yourself”, but “Some redundancy is healthy, some isn’t”, and using abstractions when you’re sure you want to couple things together.

It isn’t “Each thing has a unique component”, or other variants of the single responsibility principle, but “Decoupling parts into smaller pieces is often worth it if the interfaces are simple between them, and try to keep the fast changing and tricky to implement bits away from each other”.

It’s never “Don’t Rewrite!”, but “Don’t abandon what works”. Build a plan for migration, maintain in parallel, then decommission, eventually. In high-growth situations you can probably put off decommissioning, and possibly even migrations.
dry  srp  programming  bestpractices  refactoring  maintenance  modularity  onethingwell 
27 days ago by cdzombak
Seacoast Reliability Project decision expected by early December - News - seacoastonline.com - Portsmouth, NH
Whether Eversource will be approved to build a 12.9-mile high-voltage transmission line that traverses mostly through Durham and Newington could be decided before the beginning of December.
seacoastonline  SRP  sec  publichearings 
28 days ago by eversourcenh
Great Bay Towns Turn Out Against Transmission Line | New Hampshire Public Radio
At least 150 Seacoast residents packed a state hearing Thursday night to urge regulators to reject a proposed transmission line.
nhpr  SRP  publichearings 
28 days ago by eversourcenh
Residents voice opposition over transmission line | State | caledonianrecord.com
New Hampshire residents say a proposed high-voltage transmission line that would run between Madbury and Portsmouth would harm the area's ecosystem.
CaledonianRecord  associatedpress  SRP  publichearings 
28 days ago by eversourcenh
Seacoast Reliability Project faces public hearing
Nearly 50 people are scheduled to speak at a public hearing on Eversource’s Seacoast Reliability Project Thursday. All but two of the speakers are either from Durham or Newington, the two towns that stand to be most heavily affected by the proposed high-voltage transmission project.
fosters  SRP  publichearings 
4 weeks ago by eversourcenh
Don't let Eversource destroy Newington
Myself and all other Newington residents must stand up and be heard as we fight to maintain the rural character and natural beauty of our village. Eversource is fighting to have huge transmission lines run right through parts of our town!
seacoastonline  letter  SRP  opponent 
4 weeks ago by eversourcenh
N.H. Regulators Begin Hearings on Eversource's Proposed Seacoast 'Reliability Project' | New Hampshire Public Radio
Hearings began Wednesday on Eversource’s proposed transmission line between Madbury to Portsmouth.
nhpr  positive  SRP  sec  hearing 
10 weeks ago by eversourcenh
Final Hearings Set To Begin On Eversource's Seacoast Power Line | New Hampshire Public Radio
Final hearings are scheduled to start this week on Eversource's proposed Seacoast transmission line – but delays at the state Site Evaluation Committee are still possible.
nhpr  SRP  sec  hearing 
11 weeks ago by eversourcenh
Editorial: High tension moment for Seacoast Reliability Project
Blackouts disrupt our lives and hurt our businesses and we can all agree electricity providers should do what they can to keep them to a minimum.
seacoastonline  positive  editorial  SRP 
11 weeks ago by eversourcenh
Sides square off on Seacoast transmission-line plan | New Hampshire
A proposed $84 million transmission-line project that would be buried partly in Little Bay pits a need for more capacity to transmit power through the region versus concerns over disrupting the bay.
UnionLeader  positive  SRP  sec  hearing 
11 weeks ago by eversourcenh
Neighbors claim Eversource project could imperil eagles
A pair of nesting bald eagles on a Durham property on Little Bay will be in danger should a proposed public-works project come to fruition, according to a group of concerned neighbors.
fosters  positive  SRP  eagles  environment  littlebay 
august 2018 by eversourcenh
Neighbors claim Eversource project could imperil eagles
A pair of nesting bald eagles on a Durham property on Little Bay will be in danger should a proposed public-works project come to fruition, according to a group of concerned neighbors.
seacoastonline  SRP  eagles 
july 2018 by eversourcenh
Eversource Energy - Study Supports Proposed Burial Method to Cross Little Bay
A study comparing potential methods to cross Little Bay with a new power transmission line has confirmed that the proposed burial of the line in the bottom sediment of the bay will have minimal impact on the environment, the least disruption on area residents and properties, the lowest cost, the shortest schedule and is the most appropriate method.
electricenergyonline  positive  SRP 
july 2018 by eversourcenh
Eversource Study Supports Using 'Jet Plow' To Bury Power Line Under Little Bay | New Hampshire Public Radio
Eversource is doubling down on what it says will be the best way to run a new power line under the Seacoast's Little Bay. 
nhpr  positive  SRP 
july 2018 by eversourcenh
Eversource: Seacoast power line to cost $84m to $216m | New Hampshire
A proposed 13-mile transmission line on the Seacoast to help handle increased electricity demand would cost $84 million to $216 million to build, according to Eversource.
UnionLeader  positive  SRP 
july 2018 by eversourcenh

« earlier    

related tags

2017  adjunct  alternative  amazing  amp  art  associatedpress  aws  backward  bestpractices  blog  board  buildabetterworld  caledonianrecord  cds  code  cognito  columbia  compatibility  conditions  cost  delay  deployment  des  design  development  discussion  download  dry  durham  eagles  editorial  electricenergyonline  engineoverview  environment  environmental  environmentalists  experimental  failure  forum  foster's  fosters  goslingroad  graphics  greatbay  hap  hb145  hd  hdrp  hearing  homekit  hpg2017  ifttt  indepthnh  innovation  isolation  iteration  jetplow  jetplowing  kokain  lactobacillus  lambda  letter  littlebay  lwrp  maintenance  message  modularity  mvrp  natalyatatarchuk  nh1  nhpr  northernpass  onethingwell  opponent  opponents  paint  pake  password  passwords  peer-reviewed  periodontitis  petition  pictures  pipeline  planing  portsmouthherald  positive  principle  prize  probiotic  programming  protocol  public  publichearings  rally  recycled  refactoring  reliability  remote  render  rendering  research  responsability  reuteri  root  rusmidler  scaling  schedule  scriptable  scriptablerenderpipelines  seacoastonline.com  seacoastonline  sec  secure  security  shaheen  shared  single  siting  software  solid  srp6a  study  technicalsession  teen  therapy  transmission  underground  unionleader  unity  versioning  volunteers  wordpress 

Copy this bookmark:



description:


tags: