Breaking Bytes

Climbing Life Lessons: Failure

2025-02-17T00:00:00-08:00

Life Lessons from Failure

Failure is inevitable, learn if you can
Prepare & know your competencies
Value the experience of others
Show the proper humility & respect

Failure is inevitable

It's important to accept that mistakes happen to everyone. If we're lucky, and the consequences aren't terrible, we have a chance to learn something. Then our mistakes aren't what define us, it's how we handle them that matters. Thinking back I've had lots of chances to learn from my mistakes on the rock, in the backcountry, and even in the gym, so I guess I've been pretty lucky. I think my climbing failures come in four flavors:

unknown risk
inexperience & insufficient skill
carelessness
hubris

Matthes Crest

One of my earliest climbing experiences was on Matthes Crest in the spectacular high country between Tuolumne Meadows and above Yosemite Valley.

Image credit: Yosemite Climbing Association

Unfortunately, our traverse of this magnificent route was cut short when I fell a small distance landing on my back on some rocks. It knocked the wind out of me, and I bruised my ribs bad enough that it was hard to breathe. I was so embarrassed that I couldn't stop laughing which was also painful. What happened? Why did I fall on such an easy route? I think I can chalk this up to a combination of unknown risk, inexperience, carelessness, and hubris. I had never climbed outdoors before, and falling wasn't my only mistake on this route. I also lost my belay device which fell off my locking carabiner that either wasn't locked or somehow unscrewed itself. There wasn't a lot of exposure where I fell, but I failed to evaluate the risk and decided on a risky boulder move, without considering the consequences. I was clearly careless, and I think I was overconfident. The rock is merciless and quick to deal out stern lessons whether you have the aptitude to learn from them or not.

Another climber also injured on Matthes Crest offered this piece of wisdom in an AAC incident report:

One lesson is: no matter how easy the climb is you have to pretend it’s the hardest thing you ever did.

Sons of Yesterday + Serenity Crack

The most terrifying fall I ever had was on the rappel between Sons of Yesterday and Serenity Crack. A similar incident was reported in this article in Climbing Magazine: "Five Preventable Yosemite Climbing Accidents":

Multiple such incidences have occurred at this location, sometimes injuring the party.

In my story however the climber ahead of me also spun out of control, so I had warning that I would be working against gravity to make it to the anchors, but I didn't have the skill or experience to avoid spinning out of control and over the edge. Luckily, the first climber, had already tied the rope ends to the anchor, and my helmet kept me safe, but I still bashed my hand and fingers and ripped open a large gash on the back of my shoulder. I still consider how lucky I am to be alive, and that I had a more experienced climber with me.

The Warm Up Wall, Owens River Gorge

The most painful and embarrassing fall was near Bishop at a popular climbing area that I have been to many, many times. I was careless and foolish, being silly, talking too much, and not paying close attention while on lead, and before I knew it I'd slipped, fell a short distance, and hit a ledge twisting my ankle and nearly flipping before being caught by my last piece of protection. I felt like the climbing gods had struck me down for disrespecting them, and I deserved it.

The Gym

My most recent injury happened bouldering at the gym. Having been stymied all night because I am so horribly out of shape, I insisted on topping out on a high ball after already downclimbing because I didn't feel safe. I wish I'd followed that first instinct, because on my second attempt, I was too tired to downclimb and dropped several feet to the mat, losing my balance and landing badly on my arm which twisted at my elbow. Later while icing my elbow, I saw someone else top out, and realized there were rungs set next to the route to easily downclimb to a safe height before dropping. I really wish I had scoped out that landing better or talked to some other climbers before attempting it the second time. Many months later, my arm still hurts, and I had several visits to doctors and x-rays to make sure nothing was broken. This lesson was a bitter pill to swallow, after climbing for so many years, that I still had so much more to learn.

Lessons Learned

Be prepared for the risk. Learn what skills are required and know your competencies. Go with more experienced climbers, listen to them, and follow what they do. Pay attention, be serious, and don't fool around. Don't be afraid to back off of a climb for safety, even at the gym. Scope out your approach, your route, your landing, and your descent carefully before committing. Talk with others and get the beta. And when accidents happen, take the time to do the hard work to learn from them, bounce back, and then keep climbing!

PV Electric Mismatch in Silicon-Cell PV - Part 2

2024-08-23T01:10:00-07:00

Note: This post is part of a joint blog with my colleague Kurt Rhee: Primer on Electrical Mismatch

The many shades of PV electrical mismatch

Effects from shade are complicated, but can be summarized in two orthogonal categories:

shade parallel to strings
shade perpendicular to strings

These categories were defined in the Fast Shade Model [1, 2] developed by Dr. Bennet Meyers after simulating hundreds of different shade patterns and grouping them by their electrical mismatch.

shade parallel to strings

One example of shade across all modules that is parallel to strings, is row-to-row shade in fixed-tilt systems, typically in winter. When I originally wrote about PV electrical mismatch, I analyzed this type of shade using PVMismatch to simulate shade across the bottom row of a single string of 10 modules in a 10 string system. The conclusion of that post was that the string performed as well as the most shaded cell, so even though only the bottom cells were shaded, the modules in the string lost most of their power. I shaded the bottom cells 80% to simulate only diffuse light, and the string lost roughly 80% of output. The other 9 strings operated at full capacity, so the system only lost 8%. The NIST ground mount array is an example of a system that will have row-to-row shade in winter that will cause most of the strings to lose almost all of their output even when only the bottom row of cells is shaded.

shade not parallel to strings

However, that post also contained a picture of a rooftop with non-uniform shade that was not consistent across each module of the string. The shade cast from the roofline cut diagonally across the modules in the string, which was wrapped in two rows to fit.

I didn't analyze the shade from this system in that post, so it raises the question whether the rule of thumb I recommended would still apply?

shade perpendicular to strings

To simplify the question, the rest of this post analyzes a PV system with a shade obstacle like a wind turbine, a telephone pole, or a chimney, that casts shade perpendicular to the strings. My analysis is in this Jupyter notebook on Google Colaboratory: mismatch_vs_strings.ipynb

TL;DR: When shade cuts perpendicular to strings, cells go into reverse bias, bypass diodes activate in the shaded submodules, and the other modules operate at higher voltage to match the voltage of unshaded parallel strings.

I simulated perpendicular shade on the first half of the first module in the string, while the rest of the strings were unshaded. For example, this shade could be caused by a chimney. Then I increased the number of unshaded strings to see if it changed the effect. The effect of a shadow perpendicular to the string caused bypass diodes to trigger. Adding more strings did not stop the bypass diodes from triggering, even after 20 parallel strings. The IV curve of the system had a kink until 4 unshaded parallel strings were added, but after 9 unshaded parallel strings were added, the IV curve appeared unaffected. After 19 unshaded parallel strings were added, the total power loss was only 0.85% for the system compared to unshaded. However, the power loss in the shaded string was about 15%.

Here is the IV curve of the 20 string PV system with perpendicular shade on the 1st module of the 1st string from the Jupyter notebook. It looks unaffected!

Now check out the IV curve of the string with the shaded module. It should be generating about 3200[W], but even though it's lost about 500[W], it still operates at 5[A], nearly the same current as the other strings. It still has to operate at the same voltage as the other strings, 538.7[V] in this example, so how does it do it with 2 bypass diodes activated?

A look at the module IV curves tells the rest of the story. The shaded module still has to carry the 5[A] of the string, but 2 bypass diodes are triggered so the voltage is down 75%. Note: these are SunPower/Maxeon 320[W] modules, that have 96-cells in 8-columns with 3 bypass diodes in a 24-48-24 cell arrangement.

However, the unshaded modules make up for the lost voltage in the shaded module by operating just above the max power point. This is why the string is operating at 5[A], to increase the voltage in the unshaded modules. Very clever! Go team! Luckily for the shaded module, that current is also very close to its max power point, which is only down 75% thanks to the activated bypass diodes. Recall in the parallel shade scenario, the entire string was down.

Please check out mismatch_vs_strings.ipynb because the 1-string example isn't limited by the voltage of parallel strings, so it's free to operate at the max power point, and the losses are lower. Recall in the 20-string example, the shaded string lost about 15%, but in the 1-string example, the loss was only about 8%. Another variation is allowing the shade to cross two or more strings. I covered a scattershot of scenarios and found that parallel string voltage began to dominate sowmhere between 5 to 10 strings. Of course, that only applies in this contrived example, but it was interesting nonetheless.

Conclusion

I wish I could say, that's all there is to it, but as I said in my first blog post, electrical mismatch in crystalline silicon is very counter-intuitive. That's why I created PVMismatch to begin with. I was tired of guessing and being wrong. So don't guess. Simulate with confidence, try PVMismatch, and let me know what you learn!

Epilogue

So back to that rooftop with the diagonal shade line. It's a bit of both categories right? How do you think it will perform? Will it lose nearly all of its power or will bypass diodes active and save the day? Or maybe something in between or completely different. Try to analyze it using PVMismatch. If you need help I analyzed it in this Google Colab notebook: nonuniform-rooftop-shade.ipynb

References

Meyers, B., Mikofski, M. A., & Anderson, M. (2016). A Fast Parameterized Model for Predicting PV System Performance under Partial Shade Conditions. In IEEE (Ed.), 2016 IEEE 43rd Photovoltaic Specialists Conference (PVSC) (pp. 3173–3178). IEEE. https://doi.org/10.1109/PVSC.2016.7750251
Meyers, B., & Mikofski, M. A. (2017). Accurate Modeling of Partially Shaded PV Arrays. In IEEE (Ed.), 2017 IEEE 44th Photovoltaic Specialist Conference (PVSC) (Vols. 2017-June, pp. 3354–3359). IEEE. https://doi.org/10.1109/PVSC.2017.8521559

Climbing Life Lessons: Reassessing Changing Risk

2023-07-14T00:00:00-07:00

Reassessing Risk in Mountains

Snake Dike is on the southwest shoulder of Half Dome, perhaps the most recognizable rock face in Yosemite Valley. Although considered a moderate climb, rated 5.7 R, it's sometimes called "Snake Hike" because it's a serious commitment with huge exposure.

Understanding risk on Snake Dike is important. This climb requires planning, good timing, a bit of skill, and lots of luck. More importantly though, you need to be constantly aware of changing conditions, how they can affect your risk, and whether bailing is still an easy option. Evaluating risk is one of climbing's life lessons.

Snake Dike is an all day climb. The approach is a 6 mile, 3-hour hike up 2500-ft that starts at Happy Isles behind Curry Village and follows the Mist Trail, one of my favorites. Unfortunately, our 4am start was quickly foiled by rain, but our good timing gave us some flexibility, so we decided to wait it out for at least an hour and then reassess. Lucky for us our patience was rewarded, and within the hour we were back on the trail. We decided to pick up the pace a bit to make up for the lost time. Getting caught in a thunderstorm can have deadly consequences for climbers, so even though there was no rain in the forecast that day, we didn't know if the weather would turn bad again later that afternoon. Same as for climbers, descending the cables from Half Dome in a thunderstorm is a death sentence. We also didn't want to hike out in the dark, although we had brought our torches and some emergency overnight gear just in case. There's always trade offs to consider in the backcountry, so we tried to pack as lightly as we could to move fast yet still be safe. There's a saying in the mountains:

Speed is safety.

It means don't waste time, so we didn't. Ok, well maybe we stopped to take a few photos of the breathtaking views near Lost Lake.

I had climbed Snake Dike once before with a large group of experienced climbers, and I'd been on the Mist Trail numerous times, so I had good intuition for finding the right path to turn off the trail, and miraculously we nailed the approach. We ate a quick snack, tied on our climbing shoes, strapped on our harnesses, clipped on a light rack (mostly slings & quickdraws), and tackled the first pitch which is actually one of the 5.7 cruxes of the climb. The "R" stands for "runout" which means there's no protection. That pretty much describes most of Snake Dike, but the first pitch is especially gnarly. It starts on typical Yosemite glacial polish with tiny microedges that you can friction climb up to a roof where you can finally place your first solid piece and exhale a huge sigh of relief. If you slip on this slab, you'll get some serious scrapes as you tumble back to the base of the climb. In researching for this blog, I read an incident report from YOSAR about a couple that were off route but slipped on similar frictiony slab, tumbled to the base, and dragged the belayer, who was not clipped to anything, off her ledge and into a talus field. She had a punctured lung, a fractured pelvis, and broke two vertebra. Climbing can be especially dangerous if you're unlucky, don't take precautions, and fail to assess your risk carefully. I'm not trying to scare you, lots of things are dangerous, that's why it's important to know your risk and make conscious decisions. Anyway, I pulled the roof, shimmied up to the ledge and made the only anchor with pro I'd need during the entire climb. From there on out is was bolt city.

That's the SERENE anchor, a cordelet with 3 equalized cams, a la climbing anchors by John Long. Pay attention to that black webbing because it's got a bit part in this story later on. I swear my second has a backup clove hitch on a 4th piece out of the frame you can't see, so he can escape the belay.

There's one more sketchy traverse on frictiony slab protected by a single bolt, and then the rest of Snake Dike is all jugs and 5 easy. You should download the free supertopo if you're serious about climbing Snake Dike. I had tried to memorize it, because there are so many bolts on this climb that it's easy to either stop early or skip an anchor. People talk about girth hitching chicken heads but the dike doesn't really take protection. It's just a long juggy extrusion that you follow like a ladder.

All the rest of the pitches are juggy and positive but super runout with just a single bolt every 60 feet or so. In fact, some of the pitches don't have any bolts! Another interesting twist is that every so often you come across a pair of bolts that looks like an anchor, but is for shorter ropes. Knowing where to belay is part of route finding that can speed up your climb and remember, "speed is safety!" Clip the wrong bolts though, and you might find yourself and your partner simul-climbing.

The climbing was smooth, and the views were spectacular. Take a moment to appreciate this sweeping vista starting to your left past Glacier Point right to the valley floor. Is that El Cap off in the distance?

Look just a little further to the left though, and you can see what I was seeing. Dark clouds gathering around Liberty Cap and Mt. Broderick were moving our way. We needed to pick up the pace, or we would end up with only bad options.

Is there anything that is purely deterministic? I believe almost every event has a distribution of possible outcomes, some good, some great, some bad, and some very bad. Lucky or not, those possibilities aren't usually random, some outcomes are more likely than others. So now I had to weigh the odds that we could summit and descend before it started raining. The main danger for climbers in the rain is lightning. For a quick primer check out this Climbing Magazine article, Don't Get Struck By Lightning.

In my haste, I made a tactical error. After clipping a pair of anchor bolts, I decided to pass them thinking they were for shorter ropes, but before I knew it I was literally at the end of my rope. I had clipped the bolts between me and my second, and I knew there was another pair of anchors just up ahead. I felt confident so I decided to start simul-climbing, and I yelled down to my partner, "START CLIMBING!" A 60-meter rope is almost 200-ft long, and in the vastness, sounds get blown away, so I just started pulling on the rope forcing him to follow me upward. This worked for a few feet but then I was yanked to a stop. I could see the next pair of anchors, but they were just out of reach. I turned around to start screaming frantic, feeling the buzz of adrenaline shoot into my veins, when I saw my partner take off his backpack. I was completely confused. Dread crept into my bones as I saw something flutter off into the breeze, but I was quickly filled with relief as my partner slung his backpack and lept upward. I flew to the anchors, clipped them like a baby hugging his mother and hauled up my second. "What the heck was that?" I asked as he got closer, and he explained that he had climbed to the end of that black piece of webbing, but it was too tight, and he couldn't reach down to unclip the locking carabiner I'd lent him, so he cut the sling and left the biner. It was a small price I was happy to pay.

Mini epic almost over, the rest of the climb was uneventful. We reached the third class scramble while there were still patches of blue in the cloudy skies, but once on the summit, while taking victory photos and scarfing food, it started snowing and we knew we had to sprint down the cables.

We reached the bottom and started planning our celebration with cocktails at the Mountain Bar at the Lodge. There we reflected on the choices we made during the day as the conditions changed, and we reassessed our risk. Our planning didn't consider the surprise mini-epic, but a little skill and a lot of luck kept us safe. I don't think either of us were particularly risky, even before we had kids. Sure, there's a spectrum, and each person has to make a conscious choice of the risks they're willing to take, but to do that effectively requires understanding and evaluating the risk especially as conditions change.

Here's me 20 years ago, after that Snake Hike, on the infamous diving board, overlooking the valley. I reflect back on my climbing experiences, and I realize that of the many valuable lessons I learned in the mountains, assessing risk has been one of the most useful. Understanding uncertainty has helped me navigate an often uncertain world, and to realize that as conditions change, I can re-evaluate my risk and make different choices. You can too. Thanks for reading!

If you like this Climbing Life Lesson, check out this one on Offwidths or why it's better to stick with the plan rather than making last minute changes.

My Notes:

Any event has a distribution of possible outcomes, some that are more favorable than others and some that are definitely undesirable.
The distribution might not be random, in other words some outcomes might be more likely than others.
Risk assessment is a measure of the possibility of favorable and undesirable outcomes.
Each person's or party's tolerance for risk is a choice that depends on trade offs between the chances of favorable vs. undesired outcomes.
changing conditions force you to reevaluate the risk and make new choices.
Sometimes conditions and risk can change quickly, leaving you exposed to greater risk.
Exposure in theoretical terms is a measure of the level risk you've accepted but in practical terms it's measured in how far or long it will take to escape danger and get to help.
climbing in the mountains automatically increases your exposure because it can be difficult to escape the rock safely.
climbing in the backcountry can increase exposure significantly because in addition to a safe retreat you may also need to hike and drive significant distances before you can get help.
Dangers in the mountains include route finding, getting caught in bad weather, darkness, lightning strikes, equipment failure, missing or losing equipment, falls, injuries, death
learning to evaluate risk in changing conditions is an important skill that can have practical advantages in all aspects of your life.
it can help you tolerate uncertainty, because reality is both full of possibilities and uncertainty
it can help you rule out unlikely or scenarios with no serious consequences

OSS Organization as Leadership

2022-05-30T00:00:00-07:00

Open Source Organization as Leadership

It starts with the premise that everyone is curious and compassionate. Maybe this is what Dan Pink meant in his RSA Animate talk. He asked, "What motivates us?" His findings were autonomy, mastery, and purpose. Not money. Not leisure. Not luxury. Humans are neither lazy, stupid, nor greedy. In fact we're the opposite. This is why the second law of infodynamics is true: we steadily and continuously, against all odds and the sublime nature of the universe, continue to learn, improve, and thrive together as a species.

Okay. Again assuming this premise, so then good leadership takes advantage of these axioms by providing a framework for their organization that fosters autonomy, allows individuals to seek mastery, and creates a strong sense of common purpose. In practice this means:

Collaboration
Communication
Constructivism

Leadership that models and follows these three C's will be stronger, faster, and smarter than its opposites. An organization that is punitive, divisive, and siloed will be trapped, wither, and die.

In practice this type of organization has the following characteristics:

Flat structure
Rotating leadership
Frequent informal meetings
Free time
Opportunities to change job description
Strong mission, with loose long term planning, but detailed short term planning
Detailed diagnostics
Ambitious goals
An acceptance of failure
Celebrates individuality
Culture of pluralism
An appreciation of small things
Groom leaders and empower career growth
Give positive feedback
Share business constraints at all levels

Flat structure

In a 3C organization, everyone has an opportunity to be heard and be visible. This means there are less levels of leadership, more autonomy, but also more communication and collaboration.

Think about a free open source software project like Python. There might be be an owner or two, a rotating group of maintainers, several contributors, and many users. This is the most successful business model. A product that is completely free, thrives for decades, continuously becomes better, grows, and fuels numerous new projects.

Rotating leadership

The founder of an organization may be a visionary or a glorified figure head. She initially provided direction for the organization, but eventually, a group of leaders were chosen from the community to handle day to day functions. Some of these tasks are mundane yet critical, others creative and potentially ground breaking. If the organization draws strength from its members then many will be able to lead in different capacities. By rotating leadership responsibilities, the organization leverages every member's unique potential.

Frequent informal meetings

No one likes pointless meetings, so instead of waiting, in the age of Slack and other instant messaging, communicate immediately when required. In fact all the time. Communication is the key that makes an organization truly agile and responsive. As soon as you know a products timeline shifts, the sooner you can plan contingencies.

Free time

Without free time, ideas have no fertile soil to grow. Organizations that are overworked become dysfunctional and implode.

Opportunities to change job descriptions

In an organization that cherishes individuals, members are encouraged to seek their true calling. That may mean they move on to new challenges, or that they create new roles for themselves within the organization. Flexibility to try on different roles empowers members to seek mastery in something they value.

Strong mission, with loose long term planning, but detailed short term planning

See iterative project planning.

Detailed diagnostics

Measure what you treasure. Intuition and gut instincts will only get you so far, but data is gold. If you want your team to succeed, you need to have the facts. Data tells you where you can celebrate victories, and where you can trim the fat. Share the data with your team and make swift decisions.

Ambitious goals

Go after what you really want. What makes your team come to work everyday at the crack of dawn? Small victories are important, but only if they are working towards a larger goal.

An Acceptance of failure

Failure is the very nature of experimentation. You will fail. It's not a matter of if, only when. Model and demonstrate that failure is always an option, that we can learn valuable information, and that there's no judgement when we all put in our best efforts. Be supportive and always constructive.

Celebrate individuality

Seek different. Do not collect a team of clones. Encourage diversity and nurture it. Don't dismiss ideas that seem foreign to you. Instead embrace these as gems to be treasured and cherish the uniqueness of everyone on your team.

Culture of pluralism

Include your team in decisions and strive for consensus. Share information and collaborate. We are stronger as a team. There are no heroes who have all the answers. When celebrating victories, recognize everyone. Work hard to reap the benefits of your team's rich & diverse culture.

An appreciation of small things

Celebrate little victories. Break work down into short tasks that can be more easily grokked.

Groom leaders and empower career growth

Always be working to replace yourself. Put others on a path to leadership. Learn what teammates crave and give it to them.

Give positive feedback

Positive feedback is not the same as praise. Practice sharing detailed examples of work that you value in private with your team. Always sandwich constructive feedback. A good relationship should always have a larger ratio of positive feedback.

Your team needs to know what their motivation is, so give them the details. Don't hold back. If there's only $10 left in the bank, they won't make big plans at a time when earning cash is the priority.

Identity at the crossroads

2021-07-16T00:00:00-07:00

Who am I?

Even today, I'm still trying to figure out who I am. Several years ago I made a bulleted list. I thought I'd covered everything, but identity can't be packaged up so neatly in a box with only six facets. It's more like last year's Christmas lights all tangled in knots. You pull one side and three other strands come out.

Ethnicity

I am Cuban-American on my mother's side and Polish-Jewish-American from my father. Although, to be honest, my mother and father were separated before I was born, and while growing up I had never met my father or anyone in his family, so according to custom, I shouldn't be Jewish. However, my single mother wanted to keep all options open to me, so she raised me as a Jew, even though she herself had been raised Catholic. Therefore, I went to Hebrew school from the time I was 4 years old until 3rd grade, and I never learned Spanish, even though my grandmother who immigrated from Cuba in the 30's and spoke almost no English, frequently lived with us. You can imagine how confusing this was for me. Am I an Eastern European Jew or Latinx from the Caribbean? Even today, I still haven't figured out what my ethnicity is. I don't have a simple answer. I'm both, neither, and something else.

Immigration

When my grandmother left Cuba, she was a teenager. She never had more than an elementary school education, and she came to New York City with the family whom she served. She married one of the family sons, my grandfather, had two daughters, and was suddenly widowed. Then, my grandmother, my mother, and my aunt were deported back to Cuba where they lived for almost four years. They were finally allowed to return to the U.S., where my grandmother earned her citizenship and raised her two children by herself, working as a seamstress. So am I first generation or second? My mother immigrated to this country, even though she was born here.

Sex & Family

Three women, worked hard, raising children, without the partners that begot them. My grandmother, in a foreign country, with little formal education, only broken English, and a skill set only a servant could acquire, with a will stronger than tool steel, forged ahead, alone, making sure both her children received the education she never had. The nuns were stern at their Catholic schools, striking my left-handed aunt so she would use her right, but my mother and her sister persevered and made it through high school.

My mother went straight to community college to get her teaching credential and started working. Oh to be young and employed in New York City in 1969! How enchanting! The music, the poetry! Although it didn't work for my mother and father, she chose to keep me anyway, and like her mother made the sacrifices necessary to make sure I was healthy and happy and had more opportunities than she did as a child. We moved to California when I was three to be closer to my aunt who was also a single mother.

That was my unconventional family: my mom, my aunt, my cousin, my grandmother, and me. There were never any men in our lives other than a few of our parents' coworkers and other friends' fathers. I saw traditional families when I went to friends' houses. Lots of kids asked me about my father, if I knew him, or if I even had a father. Yep, it was weird, but to be honest, I always loved my family, and I couldn't even imagine it any other way. We always had love, and that's what matters.

So I try to be a feminist, not just because I'm grateful of the women in my family, but because it's the right thing to be. Mothers shouldn't have to make sacrifices to raise their children, no one should. All humanity should raise up and respect parents who bring forth life, nourishing it, and model the goodness we wish to see in the world.

Gender

Neurodiversity

Sexuality

Race & Color

Nationality

Intersectionality

Case for Experts in Management

2021-05-22T00:00:00-07:00

A Case for More Experts in Management

Intro

First off, let me say I don't think you need to be an expert to be a good manager. In fact, I don't even think you need to be an expert to be a good individual contributor. Sure it helps, but I believe there are other traits that are more important for making good technical contributions and better management decisions.

A mentor once told me, when hiring, look for intelligence versus skillset, because a fast & flexible learner continues to be useful when a project ends, but a finite skillset will eventually be obsolete. My definition of intelligence has evolved, and now I think he was really talking about mindsets. I believe having empathy & a growth mindset might be even more important than expertise or leadership.

Maximize Diversity

In my opinion, there's a common misconception that experts lack leadership skills, or that their unique skills are better utilized as individual contributors. However, this artificial perception blocks potential contributions from others with unique perspectives, and it creates a void of subject matter expertise & experience in leadership. Instead it reinforces the stereotype of the alpha-type boss and the nerdy, absent minded professor.

I strongly feel this lack of diversity in leadership & individual contributions is a real missed opportunity to maximize collaboration with unique voices & special experiences across an organization. This opportunity cost limits growth and sustainability, and I would bet these types of businesses die from starvation & cannibalism as experts give up, frustrated from a lack of voice, and leaders, failing to listen to these valuable perspectives, opt for short term gains and cash out before they crash & burn.

A New Model

Instead of perpetuating this rigid 20th century hierarchy, I propose a new model where empathy & open mindedness are championed for all, and opportunities are encouraged for all maximizing diversity. If a contributor excels at research or analysis, that doesn't mean they can't learn to be an empathic leader. If their work is a safe & supportive environment that encourages stretch goals and embraces failure instead of punishing it, they can grow to accomplish anything, enhancing their perspectives and adding value to the organization.

Conversely, why are non-technical workers pushed into management, limiting their opportunities to learn new skills and make unique contributions. I don't believe workers are just one thing and only have one value. They are constantly growing and bringing new values to the organization.

T-Shapes & Growth Mindsets

Several reports have expressed the importance of lateral moves and T-shaped workers [1-4]. When a manager takes an assignment as an individual contributor they learn new skills and gain new perspectives that gives them both depth & breadth in their field. This allows them to synthesize new ideas and innovations they wouldn't have had if they'd remained siloed. Similarly when experts take on the responsibility of management, they are forced to delegate work, give up control, & learn the business constraints that limit what the organization can do. These perspectives are critical. Again, as with the manager, the expert now synthesizes these new ideas and innovates in ways they wouldn't have if they'd stayed in the lab. Both of these coworkers are now T-shaped. Instead of staying in fixed roles, by embracing a growth mindset, they have created synergy.

This is what Carol Dweck was encouraging when she wrote about motivation in her 2006 book Mindset: The New Psychology of Success [5].

"Fixed-mindset individuals dread failure because it is a negative statement on their basic abilities, while growth mindset individuals don't mind or fear failure as much because they realize their performance can be improved and learning comes from failure." Wikipedia

Empathy

Empathy is always in short supply, although we all know it to be the most valuable of human abilities. Would anyone of us be alive if it weren't for the caring love of our family & friends. At work we draw boundaries, as we should, but that should not exclude empathy from the workplace. In fact, I argue it's even more important. You want people to give their best, then they have to have a safe & supportive environment where they feel trusted and respected. No punitive action is ever useful at work. Positive & constructive feedback is based on the assumption of good faith. That everyone is pulling together and giving their best for mutual success. Where failure is not criticized, but a learning opportunity for all.

Conclusion

So in summary, don't box yourself in or your coworkers. Strive to create a culture where anything is possible, learning is continuous, and failure is always an option, and that's good. Encourage lateral moves and grow a T-shaped workforce. Listen to experts and encourage them step outside of their comfort zone to take a turn at the wheel, while leaders experiment and analyze data. Don't be afraid to mix it up. The result might be a more sustainable and profitable business.

References

Climbing Life Lessons: Offwidths

2021-05-01T00:00:00-07:00

Life Lessons from an Offwidth

The East Buttress of El Capitan is one of the best but hardest climbs I've ever been on. It's long & sustained, with huge exposure & beautiful, sweeping views of the valley & Middle Cathedral. In typical Yosemite fashion, it challenges you right from the get go with a steep chimney overlooking a 1,000-foot drop. Then on the 9th pitch, after you've been climbing for a few hours, over 2,000 feet above the valley floor, there's a classic Yosemite offwidth. Like glacial polish, Yosemite offwidths are a ritual you can't avoid. You just have to stash your ego, open your heart, and humbly listen to what the great mother is trying to teach you.

That's me, 20 years ago, on that incredible, unforgettable flaring 9th pitch. An offwidth is a difficult climb. It's too big for hand jams, but too small to chimney. Everybody has advice for offwidths: armbars, heel-toe jams, chicken wings, kneebars, shoulder jams, handstacks, liebacks, you name it. About the only advice worth following comes from climbing and squirrel suit legend Steph Davis:

I think the biggest thing with offwidths is to remain calm and be patient.

She makes it sound so easy! However, there's another dimension that exponentially increases the challenge. Placing protection on offwidths is no joke. First, it's no fun lugging a giant cam 1,000 vertical feet just to use it once. Oh, did I mention the 9th pitch is one of the longest? So make that two huge 5-inch cams. So far we have challenging, sustained, strenuous technique combined with sketchy, runout pro, fatigue, and huge exposure. Oh, but did I mention the breathtaking, awe-inspiring views? Look right across the yawning expanse of the valley is the mighty Middle Cathedral rock! And behold Half Dome!

Feeling good now? So what exactly is the great mother trying to teach us? Trust. Relax. Move intentionally, methodically, and don't hesitate. Above all, resist the urge to bump or reposition your pro. What's this? Remember we only have one gigantic cam with us on this slog, we're scared and tired, so it might seem logical to reach down and pull that cam up, or maybe you spy the perfect placement you couldn't find when you shoved it in desperately thinking you might slip out any second. Sometimes if you're lucky on a nice evenly spaced marathon, maybe you can bump the cam over your head a few times as you move up. However, these dream parallel chasms only exist in Canyonland sandstone. Out on the granite cliffs of the valley, unfortunately you're more likely to accidentally lose your only last good pro as the cam tips out into a sudden widening or jam in the back never to be retrieved again. Your second will curse you, other parties will praise you as they clip this fixed pro, and later a seasoned YOSAR regular will pull it out as the rock changes, reading it like an ancient magic rune. A Climbing magazine primer summarizes the cons well:

If the cam tips out or falls down the rope, you could end up way above your last piece. Worse, it could knock out that last piece—and possibly your belayer. Be careful not to push your cam into a spot that’s too tight, too tipped out to hold a fall, or out of your reach.

Of course use long slings so you don't inadvertently walk your cam out of its spot, and suffer the same fate as if you bumped it yourself. Argh! There are so many things to consider, and you're in a really tight spot (pun intended). So don't try any 11th hour dramatics. Leave the gear where it is, keep moving, find another placement deeper in the crack, maybe back it up. Climbers have an old saying that is part cheek and part truth.

When in doubt run it out.

It means keep climbing. Unless you're going to downclimb or retreat, it's better to keep making forward progress, than to burn out in a precarious situation. Chances are you will power through the moves, and more often than not the rock offers you a neat solution that saves your ass in the nick of time. But you won't have the juice to make those moves, or the brains to read what the rock is telling you, if you spin out trying to fix a piece of pro that's already your best placement.

So what's the lesson? How does this apply to me, in my office, clicking a keyboard? Have you ever had a project or a product that's about to ship? And your boss calls you at 11pm, and says, "Hey change this thing." Or maybe you're the boss, and you call your team with a desperate hail Mary pitch at the last minute. Don't. Just. Don't! Calm down. Relax. Trust your team. Stick to the plan. The most important part is sending the project. Whatever your idea is, it's just not worth it. Or maybe it is? But you better be damned sure, because you had a product ready to ship. Are you certain you really want to fuck it up on a Friday night? Why not sleep on it? Maybe in the morning, when you start getting feedback, some bad, some good, on the product that you actually delivered, you'll be glad that you didn't almost bomb everything.

This is the lesson. After the 9th pitch, the climbing on the East Buttress was still hard, not technically, but we had reached the end of our rope (no pun this time), and we were fried. There was some mundane 5-easy, exposed traversing with awful rope drag, but we made it to the top. And what a top out it was. Half Dome ablaze in the most glorious sunset of my life.

The descent is actually the most dangerous part of the climb. Something like 70% of climbing accidents actually happen when parties rap off the ends of their ropes, because they're too tired to pay attention to tiny but crucial details. We descended the famed East Ledges which true El Cap warriors rap from when they finish big wall test pieces like the Nose. There were fixed ropes that looked good enough, and we stuck the finish, with an elated sense of the sublime. The great mother had graced us with her wisdom, and we had tried our best to suss it out.

So maybe that's the lesson? To keep it all in perspective? We had planned this trip, read the guides, studied the topo maps, racked our gear with intent, rose early and given it our best. We were lucky that we didn't have to improvise. We were given a cake walk, and we ate it up.

Thanks for listening. Here's me right before the crux 10b move after the chimney. Not a care in the world.

Future of Science

2020-03-08T00:00:00-08:00

The future of science is OSS, and the language is code.

In the future money is obsolete, currency is your reputation, and you earn it but contributing to open source data, science, and software. What is open source? Software seems to dominate open source, but open science, open data, and open art are also important. Content is not only digital, but also material. An open science experiment or open educational lesson plan. It's the ultimate socialist sharing economy. So how does it thrive?

Electric Mismatch in Silicon-Cell PV is Not Intuitive

2019-10-18T15:23:00-07:00

Uniform Versus Non-Uniform Shade

The counter-intuitive effect of shade on photovoltaic (PV) solar energy panels surprises most people.

Shade across a relatively small portion of the panel can cause a disproportionately large power loss.

For example, shade across just the bottom row of cells, only 6 cells out of 60, merely 10% of the PV panel, will cause 90% power loss! Why does this happen? Did you think it would cause only 10% power loss? Why isn't power loss linear with shade?

OK, to be fair, if the entire array is uniformly shaded or merely illuminated with a less intense light, then the decrease in power would be proportional to the decrease in light intensity. For example if a giant rain cloud passed over the sun, or the sun slowly sank behind a mountain, so that the same light was cast everywhere, but just lower intensity, say 50%, then the power would be 50% lower as well.

So just to be completely clear, in this post we are not going to talk about the effects of changes in light intensity that are totally uniform everywhere, but instead we're going to focus on what happens when there are non-uniform differences in light intensity across the PV system. Here's an example of a PV system with non-uniform shade.

PV Primer

In PV lingo, a panel is called a module which, in most silicon PV modules, is made up of smaller solar cells connected in series. Modules are most often connected in series to form strings of modules. Strings are connected in parallel to an inverter which converts DC from the panels to AC which is sent to the grid.

Here's a typical PV system at the National Institute of Standards and Technology (NIST) in Gaithersburg, MD, which has a single 260-kW inverter connected to 96 strings, each with 12 Sharp NU-U235F2 235-W modules. The first four rows are 5 modules deep, but the last row is only 4 modules deep. The modules are all in landscape and have straight stringing:

Here's a simulation from SolarFarmer showing the shadows cast by the eastern trees.

PV Cells and Reverse Bias Breakdown

The cells in a PV module can be considered roughly as a current source in parallel with a diode and some resistive elements. Diodes are semiconductors. In other words, they only conduct current in one direction, called the forward bias. When a negative voltage, or a reverse bias, is applied to the cell, the semiconductor won't conduct a current. However, if enough reverse bias is applied, all semiconductors will eventually breakdown, and carry a current. This phenomema is called reverse bias breakdown, and the breakdown voltage varies between cell technology. A typical front contact p-type silicon solar cell may breakdown at around -20 volts, while a back-contact n-type silicon solar cell may breakdown at -5 volts. There are many factors, beyond the scope of this primer, that affect reverse bias breakdown, such as purity of the substrate as well as type and concentration of dopant. The most important thing to understand about reverse bias breakdown is this:

When a cell is in reverse breakdown, it can carry nearly any current, but because the voltage is negative, then the cell will dissipate energy and will get hot as it exchanges heat with the environment around it.

The Single Diode Model

The electric circuit analog used to describe a solar cell is called the single diode model. Here's a schematic:

Image credit: Sandia PV Performance Modeling Collaborative

The solar cell current-voltage relation, or IV curve, shown below demonstrates the forward and reverse bias characteristics of a solar cell. The single diode model matches this response close enough to be used for predictions.

Image credit: PV Education, UNSW, ASU, et al.

PV Modules and Bypass Diodes

PV modules are usually designed with bypass diodes to avoid energy loss and hot spots due to cells in reverse bias breakdown by allowing current to bypass the cells in reverse bias breakdown. The figure below shows a 72-cell module with 3 bypass diodes, each in parallel with a 24-cell submodule (aka: substring).

Credit: Analysis of Power Loss for Crystalline Silicon Solar Module during the Course of Encapsulation by Hong Yang et al., April 2015, International Journal of Photoenergy 2015:1-5 DOI: 10.1155/2015/251615

When the voltage in the submodule exceeds a small trigger voltage in the bypass diode, due to a cell or cells in reverse bias breakdown, then current will flow through the bypass diode, bypassing the entire submodule. For example, if one cell in the submodule is in reverse bias breakdown at -20 volts, and the other 23 cells are all normal at 0.6 volts, then the total voltage of the submodule is -6.2 volts.

$$\begin{align}V_{sub} &= -20[V] + 23\left(0.6[V]\right) \\ &= -20[V] + 13.8[V] = -6.2[V]\end{align}$$

So if the trigger voltage of the bypass diode is -0.5 volts, then the current will pass through the bypass diode. If the module current is 6 amps, then the bypass diode dissipates only 3 watts and avoids losing 36 watts from the bad submodule. What's more important than saving energy though, is that the bypass diode is also a safety device, because the single cell in reverse bias breakdown would have dissipated 120 watts, which could potentially cause a fire, and most likely would cause permanent damage to the cell and the module encapsulant or backsheet.

Electric Circuit Theory

So why does non-uniform shade cause this non-linear effect? If we consider the PV system as an electric circuit, then it must obey the following two laws:

Ohms Law

According to Ohm's law, because the cells and modules in a PV system are all in series, then they must all carry the same current, $I$, the total voltage of each module, $V_{mod}$, is the sum of the cell voltages in that module, and the total string voltage, $V_{str}$, is the sum of the module voltages in the string. In the equation below, $Z$ represents the impedance of each cell in a module or each module in a string.

$$V = \sum V = I \sum Z$$

The actual relation in a cell is really a bit more complicated than $V=IZ$, but hopefully this will do to explain electrical mismatch for now. The relation between the flux of charge and solar cell voltage is described by the Poisson Energy Transport Equation but in practice the single diode model circuit discussed above, is a useful analog. For more detail on the single diode model, see this post on examples of implicit vs. explicit solutions for PV systems.

Kirchhoff's Law

Kirchhoff's law requires the voltage across all of the parallel strings to be the same as the voltage across the inverter, and the total current at the inverter nodes to be the sum of the currents from all parallel strings connected to it.

$$I = \sum I = V\sum{\frac{1}{Z}}$$

Electrical Mismatch

The combined effect of enforcing Ohm's and Kirchhoff's laws on a PV system that is partially shaded can cause what's called electrical mismatch. In other words, the shaded cells can't match the current being carried by the rest of the module, or the string with shaded modules can't carry the same voltage as the PV system, and therefore the entire system has to find a new operating condition to satisfy Ohm's and Kirchhoff's laws.

A Rule of Thumb

The counter intuitive behavior of a PV array with partial shade can be understood by remembering the following rule of thumb:

A submodule will perform as well as its most shaded cell.

Imagine a submodule has the bottom cells completely shaded, so they are only getting diffuse light, say 10% of the total plane of array irradiance that's incident on the other cells in the module. The rest of the PV array is operating normally, so the current and voltage of each string might be 7.8 amps and 360 volts, assuming the NIST site shown in the PV Primer above. So, as described in the section on PV Cells and Reverse Bias Breakdown, the two shaded cells can only carry this current in reverse bias breakdown, which would trigger the bypass diode to activate, and cause the string to lose one-third of a module's voltage. However, the strings all have to have the same voltage, and the maximum power point of the system is not going to be at lower voltage, so the bad submodule can't activate it's bypass diode, and the string will have to operate at a lower current - the same current as the bad cell.

PVMismatch

We can analyze this using PVMismatch Python package by SunPower.

TL;DR: A PV system with just 10% of cells shaded in only 1 string, loses nearly all of the power in that string.

Script

The following scrpt uses PVMismatch to model a PV system at STC with 10 strings of 10 SunPower SPR-315E-WHT 96-cell modules per string. Then analyzes the same system, but with the bottom row of cells shaded 80%, ie: only diffuse irradiance:

"""
analyze and plot a 10x10 system with bottom cells of one row shaded
"""

# import the pvmismatch library
from pvmismatch import *

# import the matplotlib plotting library
from matplotlib import pyplot as plt

# make a 10x10 system of SPR-E20-315 96-cell panels at stc
pvsys = pvsystem.PVsystem()

# plot the system
pvsys.plotSys()
plt.tight_layout()

# shade the bottom cell of all modules in the 1st string by 80%
pvsys.setSuns(
    {0: {m: {
        'cells': (11, 12, 35, 36, 59, 60, 83, 84),
        'Ee': (0.2,) * 8} for m in range(10)}})

# plot the btm row shaded system
pvsys.plotSys()
plt.tight_layout()

# btm row shaded system max power
pvsys.Pmp
# 29607.549997102204

# make a new stc system for comparison
pvsys_stc = pvsystem.PVsystem()

# stc system max power
pvsys_stc.Pmp
# 32119.317380452303

# calculate loss
(pvsys_stc.Pmp - pvsys.Pmp) / pvsys_stc.Pmp
# 0.07820114461332704

# btm row shaded string max power
pvsys.pvstrs[0].Pstring.max()
# 720.6607971888608

# stc string max power
pvsys_stc.pvstrs[0].Pstring.max()
# 3212.7324983909575

# calculate loss
(pvsys_stc.pvstrs[0].Pstring.max() - pvsys.pvstrs[0].Pstring.max()) / pvsys_stc.pvstrs[0].Pstring.max()
# 0.7756860250426105

# plot stc string
pvsys_stc.pvstrs[0].plotStr()
f = plt.gcf()
f.axes[0].set_ylim([0, 8])
plt.tight_layout()

# plot btm row shaded string
pvsys.pvstrs[0].plotStr()
f = plt.gcf()
f.axes[0].set_ylim([0, 8])
f.axes[1].set_ylim([-100, 1000])
plt.tight_layout()

The maximum power at STC is 32,119 [W].

The maximum power with bottom row shaded) is 29,607 [W]. The calculated the relative loss, (pvsys_stc – pvys_btm_row) / pvsys_stc, is 7.8%.

The string power at STC is 3213 [W].

The string power with the bottom row shaded is 721 [W], and the calculated relative loss, (pvstr_stc – pvstr_btm_row) / pvstr_stc, is 78%.

(Sorry the resolution is a bit poor around the knee, this was a quick simulation using only 100 points.)

OAuth 2.0 and OpenID Connect Primer

2019-10-17T17:30:00-07:00

Authentication and Authorization

Web applications may contain both public and private data. Private data may be further restricted to only certain authorized users. Therefore the web application must first authenticate a user, and then determine what private data they are authorized to access. The OAuth 2.0 specification implements an alternative workflow which alows users to authorize another web application to access resources on their behalf. The specification states that OAuth 2.0 is not an authentication protocol. However, OpenID Connect does use OAuth 2.0 to implement a standard for authentication. GitHub is an example of the OpenID Connect standard, see Basics of Authentication.

Terms

The following definitions are from from the linked reference by Alex Bilbie.

Resource (API) server: The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.
Authorization server: The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.
Resource owner (the User): An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user.
Client: An application making protected resource requests on behalf of the resource owner and with its authorization. The term client does not imply any particular implementation characteristics (e.g. whether the application executes on a server, a desktop, or other devices).

Authorizing Users & Clients

There are four workflows supported by OAuth 2.0 that allow users to authorize an application to obtain a Bearer token to gain access to resources in lieu of user credentials or client tokens.

Authorization Code
Resource Owner Password Credentials
Client Credentials
Implicit (not covered in this post)

Authorization Code

This is the most secure workflow and is the preferred workflow for applications running on remote web servers that can store credentials confidentially. The process is documented in the OAuth 2.0 specification and in the References. The authorization code workflow consists of the following steps:

Ask an administrator to create a client application with the desired grant type. You should be given a client_id and a client_secret. These must be treated as secrets, e.g. never transmit them over HTTP, only HTTPS, and don't commit them to repositories. The client type for the authorization code workflow should always be Confidential. A confidential client can keep a secret, while a public client can't. An example of a confidential client would be a server, while a public client would be single-page JavaScript application, because anyone could view the page source. Authorization code should only be used with confidential clients that can keep secrets. The client registration must include a list of redirect URI to consume the authorization code from the authorization service.
Then a registered client can send a GET request to the authorization URL to redirect users to login with the identity provider and get an authorization code which can be exchanged by the client for an access token. For this example, we'll use the following fictitious authorization URL:
```
https://identity-provider/authorize/
```
- The authorization URL is very picky. It must include a the following query string parameters:
```
"client_id": <client-id>,
"state": <optional>,
"response_type": "code",
"redirect_uri": <redirect_uri>,
"scope": "read write email name"
```
- The authorization can also include the desired scopes including any additional claims about the user such as: email, name, given_name, family_name, openid, etc. that can be retrieved in the ID token from the /identity-provider/userinfo/ endpoint.
- Optionally, the authorization request should also contain a unique state code, a string of any length, used to prevent cross site forgery request. It's up to the client to save the state sent in the request and validate it with the state returned in the response from the authorization server.
- Optionally there may be an approval_prompt parameter that can be provided and set to either force or auto. If not set, and there is a "skip authorization" checkbox in the app registration form which is disabled, then the default may be force which may ask users to authenticate everytime. To only ask users to authenticate the first time, try auto.
- The identity provider will ask the user for their credentials if not already cached in the user's browser.
- Depending on the approval_prompt parameter or the "skip authorization" checkbox, the user may be prompted to authorize the token, with a list of the claims and scopes that the token is requesting.
- The authorization service returns a code and the state submitted by the client. The code can then be exchanged for an access token.
The redirect URI on the client side has 10 minutes, and one attempt to exchange the authorization code for an access token. This request is sent as a POST:
```
https://identity-provider/token/
```
- The token URL is very picky. It must include the client's id and secret either as a basic authentication header or as payload data. Additionally the following data must also be in the payload of the POST:
```
"grant_type": "authorization_code",
"code": <code>,
"redirect_uri": <redirect_uri>
```
- The response is a JSON string with the access_token, expires_in, token_type (always Bearer), scopes and a refresh_token.

Resource Owner Password Credentials

This can be used by trusted clients by passing users credentials directly to the authorization server, in return for a token. See the References for more info and examples.

Client Credentials

This can be used by trusted clients to use the API directly on their own behalf with any user. See the References for more info and examples.

Refresh Token

This can be used by any client to extend a token before it expires by exchanging a refresh token for a new token without requiring the user to reenter their credentials. See the References for more info and examples.

Getting User Info

This part of the OpenID Connect specification allows a client to use the access token to obtain the token owners identity and other claims such as email, name, given_name and family_name. These claims must be submitted as scopes when the authorization code is requested. Then the client can send a GET request:

https://identity-provider/userinfo/

The GET must have an authorization header containing the bearer token:
```
Authorization: "Bearer <token>"
```
The content of the response is JSON web token (JWT), a base-64 encoded string signed by hashing the JWT using the client secret as the key. See jwt.io for more information and available bindings.
The response status code should be 200 OK and the content type should be application/jwt. The status code will be 405 METHOD NOT ALLOWED if the request does not use GET and 403 FORBIDDEN if the bearer token is missing or invalid.
The JWT contains the user name as the subject claim, sub, as well as any additional claims requested as scopes.
Use the groups scope to get access to groups a user belongs to on the identity provider such as the administrator group.
It is up to the client to validate that the JWT is signed correctly. The hash algorithm is in the JWT as alg.
The JWT also has an issuer claim, iss, that should be set to the name of the identity provider.
The JWT audience claim, aud, is the the client id.
It's up to the client to check the time frame of the JWT using issued at iat, expires in exp, and not before nbf claims.
The client can also confirm that the correct token was used by examining the access token hash claim, at_hash. Please see the the OpenID Connect Core specification for more info.

Permissions

Access to resources can be limited in two ways:

permissions (not covered in this post)
token scopes

Token Scopes

If a user or an application is authenticated using an OAuth 2.0 token, then that token must have the scopes required for the desired action, regardless of the owner's permissions or group membership! For example if an application has been authorized by a member of the administrator group, then that token can only be used to edit data if it has the write scope.

Scopes and Claims

Scopes can also used as claims to identify a token owner. The following scopes and claims may be available.

Name	Description
read	Read scope
write	Write scope
groups	Access to your groups
name	JWT claim for user full name
email	JWT claim for user email
given_name	JWT claim for first name
family_name	JWT claim for last name

The groups scope can also be used as a claim to get the groups that the token owner belongs to from the identity provider.

References

Python Concurrency Primer

2019-10-07T10:33:00-07:00

Python Threading versus Multiprocessing

Threading works really well with IO, but not CPU bound processes, hence why there's an asyncio lib for IO and a MP lib. Before Py3, you could only manually create threads using the threading lib and some people who don't like asyncio still prefer to use the manual threading lib, an external lib like trio, or older packages like gevents, etc.

For an example of using threading for an IO bound process see the pvlib.iotools.get_ecmwf_macc() method which returns the thread that calls the ECMWF api client because it is soooooo slow!

Concurrency in the Cloud

Curve ball (⚾) - threading and MP work great for a single computer, but when you are on a cluster, such as web applications, then you have more options!

In a web app, you usually have a load balancer in front of several workers who answer get requests.

Therefore you can deligate the work for both IO and CPU bound processes differently than by using either threading, MP, asyncio, trio, gevent, etc.

Celery is probably the most popular task queue for distributed resources especially for web applications.

I would guess there are task managers other than Celery, but would have to Google around to find a curated list - and many examples recommend Celery, eg: Heroku.

Inter-Process Communication

Note a task queue, threading, and MP all require a way for threads and processes to communicate with each other. Threads on a single machine can more easily share memory which makes them more efficient than MP. For Python threads, I typically use the standard Python Queue lib.

Multiprocessing requires some form of inter-process communication or IPC, which attempts to serialize and deserialize objects between processes. Python provides MP Queues and Pipes to exchange objects between processes. I prefer the MP Queue, because it nearly mimics the API of the standard Python Queue lib, but because it is IPC, I have to be careful to only pass in objects that can be easily serialized and deserialized like numbers, strings, sequences, and dictionaries.

For distributed computing, the recommendation is to use a message queue like RabbitMQ or a shared memory server like memcached or reddis.

Unfortunately, I don't have the expertise to say when to use an MQ verses memcache, but there are lots of articles on the internet discussing the pros/cons of each. I've used memcache and it works, but I believe for Celery they preffer MQ.

Queues

For both threads and processes, IMHO it's a good idea to keep the communication simple. I recommend only pushing the primitive types that will be needed by the target function handled by the thread and then reconstructing more complicated objects in the main branch of execution as needed. I believe this will keep the communication overhead low as well as make it easier to serialize and deserialize target arguments and avoid race conditions.

Note: Python also uses the GIL to avoid race conditions between threads. See below.

Thread Safety and Shared Memory

This is at the edge of my experience, but Python does provide tools to lock and synchronize communication between threads and processes as well as a shared memory map for multiprocessing. Explore on your own.

The Difference Between IO and CPU Bound Process

An IO bound process is like getting data from a URL, or writing a file
A CPU bound process is like a big calculation like matrix inversion, a search routine, or optimization/minimzation problem

IO bound processes use Threads because threads do not block IO bound processes - IE: you can start an IO process in a thread and execution will continue to the next line unless you tell Python to wait. AsyncIO and Trio probably use threading in the background, IDK for sure.

CPU bound processes use MP, because they need their own core to do their stuff. But unfortunately there is a lot of overhead with MP, and so the calculation needs to be really expensive to make it worthwhile.

There's no limit to the number of threads you can create, but the number of MP processes is limited to the number of cores.

These rules don't apply to distributed computing, and they may not apply in other computing languages either. IE: you can distribute both IO and CPU tasks to a task queue across a cluster. However, there may be task managers that are better suited for different types of tasks. EG: Dask is probably better for distributed computing of CPU intense processes. But honestly, IDK, I'm at the edge of my personal research and experience here, and so I would probably recommend a little more exploration ...

Python Global Interpreter Lock

The reason there's this difference between IO/CPU and threads/processes in Python specifically, and perhaps not other languages, is because Python is single threaded by default due to the Global Interpreter Lock or GIL. Other languages may or may not have similar design, IDK, however Python C-API does let you explicitly release the GIL and manage threads manually. This is what packages like NumPy/SciPy and CPython do.

Examples of implicit versus explicit solutions for photovoltaic solar energy systems

2018-06-22T20:55:00-07:00

Full Scale PV Modeling

I want to explore different ways to find the operating conditions for max power of a PV system. I'm going to assume that we're using a single diode model (SDM) which is an analog curcuit of a solar cell composed from a current source, a diode, and a resistance in parallel, in series with another resistance.

source: Sandia National Labs: PV Performance Modeling Collaborative

The cell current in the SDM can't be solved explicitly as a function of cell voltage without using the Lambert-W function. It can be solved implicitly by using an iterative solver such as a gradient descent method. And there is an explicit method that can be used to solve for cell current as a function of an intermediate parameter, the diode voltage, which can then be used to calculate the cell current. To get a specific voltage using this explicit parameterized approach, requires solving for several diode voltages and interpolating.

A common use of the SDM is to solve for the ideal operating condition of an entire PV system by assuming all of the cells are identical. Another proposed usage of the SDM is to model all of the cells in an entire system to account for their differences either due to variance in manufacturing, ambient conditions, or degradation. This second problem poses some challenges computationally for very large systems.

What is the best method to do full scale PV system modeling? I'm going to skip the Lambert-W function and focus on implict and explicit methods.

Conclusions

The implicit approach is efficient at finding a single operating condition, even or especially when most of the cells are different, but it's slow at tracing the entire IV curve.
The implicit approach is also efficient at determining the max power point.
Nesting search methods is less efficient than a single closed solution.
The explicit method is most efficient at tracing the entire IV curve, even when every cell is different.

Gist

The following Gist contains examples for a full scale implicit approach and the explicit parameterized approach described. The Gist are best viewed on nbviewer.

SPACES: Mnemonic for core values of good modeling software

2018-05-10T00:14:00-07:00

Modeling

Mathematical models of scientific phenomena are essential in engineering. We use them to design experiments and select instruments based on estimates of the sensitivities of relationships between factors. We derive models from the experimental results and use them to develop more predictive models. Sometimes we can use models to reorganize experimental results to fit into the context of our understanding of the physical world, and sometimes this leads to the discovery of new factors and new relationships. When we are confident in our models ability to explain physical phenomena and describe relationships, we use them to predict. We can use predictive models to find solutions by optimizing our objectives. Good models are powerful, and they are the very essense of science.

Software

Computers have revolutionalized the derivation and use of mathematical models to understand, describe, and predict our universe. We use code to interpret mathematics and science into a language that computers can use to perform calculations that would have taken us years to do by hand. But just like pencil and paper work there are ways to organize code best to accomplish your objectives. Good modeling software is based on a set core values.

SPACES

SPACES is a mnemonic for the core values of good modeling software.

Simple
Perfomant
Accurate
Collaborative
Extensible
Stable

Simplicity

Good modeling software is simple. It doesn't do more or less than what it needs to do. It doesn't create more problems than it solves. It isn't convoluted or difficult to explain. It may contain complex algorithms, but the art and beauty of good code is that it makes the complex elegant. Document your code well. Use autodocumentation so that there isn't double documentation. Keep as much of the documenation in the source code as possible. Make comments that explain the intent of your code and read like a human being wrote them. Write comments to yourself. Use TODO and FIXME frequently in your code as reminders of changes you still need or want. Break up your documentation into sections based on the target audience.

Always include a Quickstart Tutorial that is one page and has simple but realistic examples!

Include a detailed but simple user guide, a separate, more detailed theory guide, a comprehensive API, and a developer guide that explains things like how to build the documentation, how the CI is set up, how the server is configured, how to deploy the software, and what conventions were used. Be detailed. Consider adding a cookbook of examples, a gallery, tutorials, or HOWTO sections. Your API should be 100% covered.

Performance

It just has to be fast enough. Usually there is a trade off between speed and accuracy, so finding the balance is tricky. But in order to be useful, modeling software must not be slow. Efficiency where possible should always be a priority. Maybe not in the first draft, but in revisions inefficiency should be removed wherever it's found. Don't repeat yourself. However, don't create overly complicated code. Efficient code should still be simple. Strive for elegance.

Accuracy

It just has to be accurate enough. Understand your uncertainties. Regardless, modeling software that is inaccurate is useless. Make sure it works the way it's expected. Validate with publicly available data and publish your results in a notebook, like Jupyter, with the analysis code so others can run your calculations too. Check the bias:

plot the distribution of the bias
auto correlate against the output
look for correlation versus time and location, by month and hour of the day, and by vertical and horizontal position
cross correlate against the inputs

Calculate the mean bias difference (MBD) and root mean square difference (RMSD). All correlations should be random and bias should be uniformly distributed. Don't validate with your training data. Save a third of the data for validation.

Include high precision test data and use it in your unit tests.

Collaboration

Work together. Science is consensus. Others have already solved your problems. Others can find new problems. Use what is out there already. Don't reinvent the wheel. Ask for help. Get opinions. Listen. Consider alternatives. Collaborate.

Extensibility

Things change. Our understanding of the physical world changes. New technologies evolve. Build in the capacity for change in your modeling software. Anticipate that your code will need to adapt. Make it easy to maintain and update. Make it extensible to customization. Modularize. Break down your model into units that can be reused, so that intermediate values can be interrogated easily, and so contributions can be made at different entry points. Consider making your application a stack with a common object that is passed from unit to unit, and can be serialized and deserialized when needed. This will make it easier to save and load state, and to scale and parallelize. It will also make it easier to test.

Stability

Good modeling software isn't fragile. It should be bomb proof. Test it. Use a unitest framework as well as some end-to-end tests. Strive for 100% coverage. Set up a CI server to test on every push to the master branch and on pulls. Don't use polynomial fits over 3rd order unless they are physical. Set limits on arguments, and handle exceptions gracefully. Make sure that equations don't blow up unexpectedly and return NaN or Inf everywhere. Make sure that units are explained in the documentation or user interface. Scale big numbers and watch out for overflows. Watch for interger division. It's okay to follow the practice of "easier to ask for forgiveness than permission" but errors have to be handled eventually, and users deserve meaningful feedback. Just make sure it always works as expected.

Spaces

Put spaces in your code. Don't be terse. Follow the coding guidelines common for the codebase.

Iterative Project Planning in Research and Development

2017-06-16T13:04:39-07:00

Objectives and Scope

The purpose of this document is to outline a successful strategy for the optimal preparation, execution and measurement of plans for open-ended research and development projects. In particular this document demonstrates the effective use of short-term iteration cycle planning commonly known as Agile, Scrum or Kanban project management. It is important to note that the methods described in this document are not applicable to projects which have well-known execution times such as engineering, procurement and construction (EPC). Also while short-term iteration cycle planning may work well for open-ended research questions, they may be combined with traditional waterfall techniques in time-limited projects.

Methods

In a nutshell, an iterative project plan has these major features:

Mission

All projects should have a big giant overriding mission statement. This is what you look at when you're really lost and trying to re-inspire your team. In other words, this is what it's all about. For example a school projects mission might be the following:

To empower students to become agents of their own learning

Goals or Objectives

In order to accomplish the mission, you need a few long-term, broad goals or objectives that point out what direction you think you need to follow. Don't be too specific here. Continuing the school environment example, some goals might be the following:

Engage students in STEAM
Reinforce literacy in every interaction
Create a strong sense of community

Release Cycle

Pick a long-term time frame to work in, during which you hope to make progress in the same direction as these goals. This is your "release cycle". For example in a school setting the release cycle might be every three months.

Milestones or Epics

Narrow down milestones for each of the broad goals that you think can be accomplished during each release cycle. These milestones are sometimes called "epics" or "projects"

Iteration Cycle

Pick a short-term iteration cycle during which you can meet with your team and measure progress on your "epics". Iteration cycles vary anywhere from weekly to monthly, but a good compromise is every two weeks. This time-frame is your "iteration" or "scrum" because you will often meet your group for a quick tally kind of like a rugby scrum.

Tasks

Brainstorm the detailed, small, atomic tasks that you think would be required to complete the epics and put them on cards in a list called your backlog. There are many online tools like Trello that are designed to make this easy, but a large cork board works just fine. An atomic task is nearly the smallest discreet unit of work you can think of that would need to be done in order to accomplish the milestone. Tasks are easily measured, and it should also be easier to predict the time necessary to complete them.

Effort

Assign each card or task an effort score. Keep the scale small; think of it as a rubric, not a linear scale, but it could loosely be proportional to time. A common effort scale might be the following:

Effort	Description	Approximate time
0	chore	any known length of time
1	easy	< 1 day
2	hard	< 1 week
3	mini-epic	> 1 week

Usually a chore is a well-defined task that is done all the time so you know exactly how long it takes. Just mark chores on your schedule and do them. A mini-epic probably means you should break it into smaller tasks, but you may try to do it as a single task anyway. Effort is used to measure progress; the data is used to normalize and prioritize future iteration cycles. Since any data is useful as long as it is carefully measured and calibrated, you may adjust your effort scale to fit your needs after several iterations and releases.

Kanban

Kanban, Scrum and Agile have many similarities. See this Smartsheet article for a side-by-side comparison. In a nutshell, Agile is a philosophy, while Scrum and Kanban are implementations of Agile. Scrum introduces the concept of a sprint or interval while Kanban introduces puts all tasks into lists or swimlanes on a board that everyone can see and manipulate. IMO forget the names and concentrate of what works best and is easiest to use. The goal is to be efficient and productive.

The simplest Kanban board can be divided into 3 swimlanes, which is the default workflow for a new Trello board:

To do (aka backlog)
Doing (aka current work)
Done (aka completed work)

You can add more swimlanes to capture other items such as:

wishlist, icebox or parking lot - items for a rainy day
won't do - items ruled out
in review - almost done
on deck - in between backlog and current work

Pomodoro

One aspect of an iterative workflow that can create anxiety is the measurement of progress and the evaluation or prediction of the time to complete a task or milestone. The Pomodoro Technique is a time management method from the 1980's that provides a concrete conversion rate between units of work and units of time. One pomodoro is typically equivalent to 30-minutes. Using the Pomodoro technique is a diagnostic tool that eliminates the need to normalize burndown rates since converting between pomodoros and time is not subjective.

Trello and Pomello

Trello is an online tool that offers a Kanban-esque board to organize tasks and iterations. The Pomello app is a plugin for Trello that integrates Pomodoro. It logs time on task, measures the number of pomodoros spent on a task and lets you move completed tasks to their swimlane when done.

Current Work (Option 1: Kanban)

This is my personal preference because IMO the workflow is much simpler since there are only 3 swimlanes. I use this with the Pomodoro Technique. At the beginning of each iteration, pull cards into the current work list and count the number of pomodoros used on each. When a task is done, move it to the "completed" list and pull a new item from the backlog. That's it!

Current Iteration (Option 2: Scrum)

Note this method won't work with Pomello, it's better to use Scrum for Trello and Burndown for Trello.

At the beginning of each iteration cycle move some cards from the backlog into a new list called your current iteration. Iterations may be numbered or identified by date or work-week as long as they are recorded. You should assign individuals or small teams to tasks and encourage frequent communication and collaboration between individuals and teams during the iteration. During the iteration teams and individuals should measure their progress by deducting points from the initial effort of each task until they are complete and the remaining effort is zero.

During the iteration communicate with your team frequently and make adjustments as needed. For example, during an iteration you might do any or all of the following:

Take new cards from the back log as needed until the iteration is over.
Reorder cards on the backlog or current iteration board to reprioritize.
Choose tasks based on their estimated effort and the remaining time in the iteration.
Reclassify a tasks as an epic and break it into to subtasks.
Reassign individuals and teams to tasks.

Burndown (Scrum)

At the end of the iteration, tally up the effort points completed, add it to the previous total and divide by the total number of iterations. Plot this data for everyone, for individuals, for all iterations cumulatively and for each iteration. These are your burndown rates. Use them to normalize team members and to determine how much effort can be accomplished per iteration.

Table 1: Example Effort per Iteration

Iteration	Bobby	Sally	Juan	Briana	Effort
1	12	4	7	10	8.25
2	6	6	9	11	8
3	8	5	7	9	7.25
4	10	3	8	7	7

Table 2: Example Cummulative Effort

Iteration	Bobby	Sally	Juan	Briana	Cummulative
1	12	4	7	10	8.25
2	18	10	16	21	16.25
3	26	15	23	30	23.5
4	36	18	31	37	30.5

Table 3: Example Burndown Calculation

Iteration	Bobby	Sally	Juan	Briana	Average
1	12	4	7	10	8.25
2	9	5	8	10.5	8.125
3	8.67	5	7.67	10	7.83
4	9	4.5	7.75	9.25	7.625

Looking at the burndown rates and cumulative effort you can make several observations:

Bobby and Briana are either the team’s top performers or are over estimating effort. Use this info to normalize the team by either using your own effort scale or pairing teammates together to see their joint effort estimates. For example if Briana is high performer, her burndown stands, and if Bobby’s performance is more equivalent to the team average then adjust it by a factor of around 85% to 7.65 instead of 9. Ditto for Sally if she is sandbagging her effort estimates, adjust hers by a factor of 1.7x to 7.65.
Now that your burndown is normalized, the adjusted team average is around 8 points of Effort per Iteration. Therefore you should only plan to add tasks summing up to around 32 effort points each iteration.
If your iteration is half over, and Juan’s queue is empty, you can only expect him to deliver around 4 effort in the remaining time, so choose tasks summing up to this or less.

Reprioritization

After calculating burndown your team can reprioritize tasks and epics, both in response to data on progress but also due to a shift in the team mission and associated objectives. Move incomplete tasks from the current iteration either to epics because they were just too big to do in a single iteration, back to the backlog because you over allocated effort or to a board called the “Icebox” or “Parking Lot” to revisit on a rainy day.

Release

At the end of the release, publish what you have. Report on it. Re-evaluate your milestones and compare to your broad long term goals and your mission. Adjust your milestones as needed. Then celebrate!

Examples

Here are some typical workflows and how you can set them up using Trello.

Kanban

Just take the default Trello layout and start working. Put ideas that come up into the backlog. Break them up into tasks as needed. Each week move some items into the current work list. When an item is finished move it to the completed list. Use the Pomello app to measure how many pomodoros they take, and use that info to make predictions about when projects will get done. That's it!

Scrum

One way to use Trello for Scrum is to set up 4 boards:

Epics
Backlog
Current Iteration by date
Icebox

Each iteration, I archive the old iteration and create a new iteration board with the date. I move cards around all the time. I only assign effort to tasks in the backlog which get dragged to the current iteration. I create links from tasks to epics and vice-versa. I put lots of comments on the cards as I make progress.

Rationale

There are many arguments for using short-term iteration cycle planning. I will list the major salient points here.

Uncertainty is Hyperbolic

Research and development projects are inherently unknowns. There may be some data that indicates around doing small isolated tasks, but predicting a string of tasks and how they will proceed from one another is not possible because as predictions move out of the data centroid and extrapolate to larger projects and longer time-frames the uncertainty explodes hyperbolically. Therefore better predictions can only be made close to the data centroid centered on small atomic tasks.

Humans are Meta Cognitively Wired

Meta cognition is understanding about how we think, and we know a lot about how we think we work.

We get a rush from checking off tasks. (Dopamine)

Using iterative project planning with shorter term iterations allows contributors to feel more sense of accomplishment because they complete more tasks, they receive recognition for completed work and have a clear sense of expectations because data is explicit and meaningful. The feeling comes from dopamine released each time we tick off a task.

We dislike wasted effort. (Endorphins)

Only tasks are S.M.A.R.T. Milestones, objectives and mission statements are only loosely structured allowing teams to concentrate on the task at hand. By spending less time planning out long-term objectives teams feel a strong sense of purpose. Nothing is more aggravating than spending a long time planning something only to have it switched around completely halfway through it. This frustration leads ultimately to burnout and dysfunction. The corollary to this is the excitement and morale boost of diving into work quickly and quickly scoring small victories. Even a few small failures here are seen as positive data toward the correct course of action because there isn’t a lot riding on them. Working hard releases endorphins, which soothes anxiety and makes us feel accomplished. A lack of endorphins however leads to anger and stress.

We are more productive when we feel self-directed and that our work has purpose. (Serotonin)

Iterative project planning allows teams to be more productive with less oversite since they participate in creating tasks and their current workload by taking tasks from the backlog. Also by leverage Agile project management software to organize tasks in iterations and calculate burndown, companies can allow management to focus on the “Big Picture” giving the entire organization a stronger sense of unity and focus. This sense of purpose and self-value comes from serotonin released as we partake in planning our own work.

We like to work in groups. (Oxytocin)

Iterative project planning is inherently designed for groups. Working together on a project build trust intimacy and ultimately synergy which multiply productivity. Understanding and valuing each other’s strengths and weaknesses makes us closer even in a professional setting. This releases oxytocin which makes us feel appreciated and loved.

Conclusion

IMHO iterative project planning is a no brainer for any research and development group. It increases productivity while reducing costs by leveraging more individual contributors and sharing leadership.

Links

Wikipedia Articles and Perspectives:

Online Tools:

Vertically Centered

2017-05-25T23:48:00-07:00

I am porting a site, and the original login box would verticaly center, even as I change the size of the window. There were several StackOverflow answers that suggested creating a CSS class, which seemed perfect, but they didn't seem to work. Then I noticed they had some JavaScript in their file to pad the top of the login <div> element. I made some simplifications using jQuery and voila!

/* Vertically center login form in window
 *
 * Args:
 *     banner (str): id of any banner or navbar elements at the top of
 *         window
 *     log_form (str):  id of div containing log form to center
 *     minht (int): a minimum height to separate div from banner
 *
 * Use this as the callback for jQuery's resize function.*/

function set_login_form_container_margin_top(banner, log_form, minht) {
var banner_height =  $(banner).height();  // height of banner
var window_height = $( window ).height();  // window height
var login_form_height = $(log_form).height();  // login form
// new height = half difference between window and banner + login form
var new_height = (window_height - login_form_height - banner_height) / 2;
console.log('new_height = ' + new_height);
// set the margin on the top of the login form container
$(log_form).css('margin-top', new_height < minht ? minht : new_height + 'px');
}

Use it on your web page with jQuery's resize function.

<script src="/static/js/vertically_center.js"></script>
<script type="">
  $(function(){
    set_login_form_container_margin_top(
        "#my_banner",
        "#login-form-container", 0);
  });
  $( window ).resize(function(){
    set_login_form_container_margin_top(
        "#my_banner",
        "#login-form-container", 0);
  });
</script>

Python-3 Virtual Environments on MS Windows

2017-05-18T11:01:00-07:00

This is a follow up from my first post on this new Pelican blog. I should have logged how I set up this, instead of the glib cliché, "usage is a snap". Here I am posting for the second time, and I'm wondering, "why didn't I just use the built in Jekyll static site generator?"

Anyway, for posterity...

Publishing to GH Pages

To publish my pages I use the Makefile that Pelican generates when you start your blog using pelican-quickstart. I may have editted the Makefile to target my GitHub master branch since I'm using User Pages or maybe Pelican asked me during the quickstart questionnaire, I can't remember. The Makefile uses a handy tool called ghp-import that copies the contents of the output directory to the target git branch. Then the Makefile publishes the blog by pushing the target branch to GitHub. The ghp-import package is described a bit in the Pelican Tips on publishing to GitHub pages, but the Makefile takes care of calling it. So all I have to do to publish my posts is execute:

make github

You could even stick it into .git/hooks/post-commit to automate publishing.

Python-3 Virtual Environment

Okay, I can't remeber exactly the reason, but ghp-import worked better in Python-3 than Python-2, and so I created a virtual environment for Python-3. This brings me finally to the title of this post. How does one create a virtual environment for Python-3? Well according to the Python Packaging Authority (PyPA) since Python-3.3 there is a built in module called venv. However the venerable virtualenv package also works just fine for Python-3.

How do these packages differ? There is one major difference that really affects me. The built in Python-3 venv module only activates in MS Windows CMD terminal or PowerShell whereas Ian Bicking's indispensible virtualenv package works in BaSH as well. This is an issue with Python on MS Windows that I encounter a lot, it's a PITA and breaks the whole concept of a common unified experience regardless of user's platform. I should be able to use Python exactly the same on any system with very minor exceptions. Since I tend to mostly use BaSH, this means that to use the built in venv module I have to switch to a MS Windows CMD shell. I guess it's not that big of a deal, but since virtualenv works fine with Python-3, I guess I'll stick with that.

Okay, there's also one other important difference. Python-3 installs all of its shared objects into the virtual environment, which is different from Python-2 which uses links mostly. This means that when you update your version of Python-3 you need to also update your virtual environment.

For the virtualenv package you'll have to create a new virtual environment on top of the old one. But for the built in venv module you can just run:

py -3 -m venv --upgrade <my-py3-venv>

where <my-py3-venv> is the name of your Python-3 virtual environment. I think the source code for both are nearly the same, and I also think that under the hood the --upgrade option is really doing exactly the same thing as virtualenv, the difference is that if you try to create a virtual environment on top of an existing one with the Python-3 venv module is will raise an exception.

Changed in version 3.4: In earlier versions, if the target directory already existed, an error was raised, unless the --clear or --upgrade option was provided. Now, if an existing directory is specified, its contents are removed and the directory is processed as if it had been newly created.

In conclusion, I don't see much difference between the two methods. So if you want to use BaSH on MS Windows, stick with the original, otherwise try the new.

Moving to Pelican at GitHub Pages

2017-04-03T13:02:00-07:00

So this is goodbye to Google Blogger and my old blog at Poquito Picante, although I'll try to keep Breaking Bytes up to date if I can figure out how to make a commit hook that posts the generated content using the Blogger API v3.

And this is hello to Pelican! I did a very quick search for static site generators like Pelican, Hyde and a few others, and Pelican quickly emerged as the most popular. Also Kenneth Reitz said to use it.

So far Pelican usage is a snap, just follow the quickstart in their documentation. So this is my very first, albeit very short, post for my new blog site. Why leave Google Blogger?

I've wanted to for a very long time, b/c I wanted to manage my blog using Git.
My old blog is now being crawled every few hours which just seems weird.
I prefer my breakingbytes handle to "Poquito Picante" which is just a silly alliteration.

For more info about me please visit me here.

Breaking Bytes

Climbing Life Lessons: Failure

Life Lessons from Failure

Failure is inevitable

Matthes Crest

Sons of Yesterday + Serenity Crack

The Warm Up Wall, Owens River Gorge

The Gym

Lessons Learned

PV Electric Mismatch in Silicon-Cell PV - Part 2

The many shades of PV electrical mismatch

shade parallel to strings

shade not parallel to strings

shade perpendicular to strings

Conclusion

Epilogue

References

Climbing Life Lessons: Reassessing Changing Risk

Reassessing Risk in Mountains

My Notes:

OSS Organization as Leadership

Open Source Organization as Leadership

Flat structure

Rotating leadership

Frequent informal meetings

Free time

Opportunities to change job descriptions

Strong mission, with loose long term planning, but detailed short term planning

Detailed diagnostics

Ambitious goals

An Acceptance of failure

Celebrate individuality

Culture of pluralism

An appreciation of small things

Groom leaders and empower career growth

Give positive feedback

Share business constraints at all levels

Identity at the crossroads

Who am I?

Ethnicity

Immigration

Sex & Family

Gender

Neurodiversity

Sexuality

Race & Color

Nationality

Intersectionality

Case for Experts in Management

A Case for More Experts in Management

Intro

Maximize Diversity

A New Model

T-Shapes & Growth Mindsets

Empathy

Conclusion

References

Climbing Life Lessons: Offwidths

Life Lessons from an Offwidth

Future of Science

The future of science is OSS, and the language is code.

Electric Mismatch in Silicon-Cell PV is Not Intuitive

Uniform Versus Non-Uniform Shade

PV Primer

PV Cells and Reverse Bias Breakdown

The Single Diode Model

PV Modules and Bypass Diodes

Electric Circuit Theory

Ohms Law

Kirchhoff's Law

Electrical Mismatch

A Rule of Thumb

PVMismatch

Script

OAuth 2.0 and OpenID Connect Primer

Authentication and Authorization

Terms

Authorizing Users & Clients

Authorization Code

Resource Owner Password Credentials