Hacking Mac Image Capture for Higher DPI Scans

I have been frustrated that Image Capture (the built in scan and camera tool on the Mac OS) seems to be limited to 600 DPI no matter what your scanner's ability. What also surprised me is when I search for it I can't find anyone else talking about this limitation. 

I do find advice on scanning that says if you want quality don't use the OS or software that came with the scanner and buy third party software like VueScan. While VueScan is amazing software that seems to support every scanner ever made, it is also difficult to use and doesn't integrate automatically into PhotoShop the way Image Capture does.

There may be a really good reason for the 600 DPI limit in Image Capture. Maybe it follows the Apple philosophy of guiding you to the right tools. They assume if you need better than 600 DPI then you should  use more advanced software. But you don't have to if you're comfortable editing a plist file.

The following procedure worked for me and I've scanned dozens of images now at 1,600 DPI using Image Capture without issue. Possibly this is like overclocking and my scanner will die sooner because something is wrong here, so follow this knowing I'm really unsure if this is a good idea.

Here's how to scan at greater than 600 DPI in Image Capture:

0. Be sure to back up the file ahead of time and check your EULA to be sure editing it is legal. (This step is a reminder that your plist file may have zero based arrays.)

1. Find your scanner in the Image Capture settings in the system library folder. Typically this is:

    Macintosh HD > Library > Image Capture > Devices

2. In this folder will be a package for every scanner that your computer connected to. In my case I was looking for "Plustek Scanner". Right click on the package with your scanner name on it and choose "Show package contents".

3. You'll now be looking at the contents of the package. Look for the scanner plist. I'm not sure if it's always the same, but for a few I checked it was always this file:

    Contents > Resources > ScannerProperties.plist

4. Open the file ScannerProperties.plist. It is an XML file, but if you have Xcode it will open it as a plist file. Either way search for the first instance of ICAP_XRESOLUTION. In XML it will look something like this:

5. Notice the array of integers. These correspond to the drop down for DPI in Image Capture. Decide on what you want to add. My scanner supports 1,600 DPI so I decided to add a 1,200 as well. If you are using Xcode be sure to set both the value and the type. The type will default to text so be sure to set it to number. In XML my entry looks like this:

<integer>1200</integer>

<integer>1600</integer>

6. In step five the X DPI is set, so now the Y DPI needs to be set identically. Search the document for the first instance of ICAP_YRESOLUTION and put in the exact same entry you did in this location as you did in step five. Also to note, the order matters.

7. Save the plist file.

8. Open Image Capture and scan with the newly unlocked resolutions.

Mustang BXR Manifold

In the early 2000s I had a website dedicated to my car (naturalaspiration.com) and over the years the most popular part about it was the information I had on it about the intake manifold. I decided to keep some of the information around as a blog post.

BXR Intake Manifold without covers

My car was a 1989 Mustang and the intake manifold was a BXR, which stands for balanced cross ram. The concept was a balanced intake where the air had straight shots to the cylinders. The first advertisement I saw for it had yard sticks hanging out of it to show how straight the paths were. Steve Turner wrote in How To Tune & Modify Your Ford 5.0 Liter Mustang, "taking the tuned runner length, optimized port line of sight, and big airflow capacity to the nth degree, the BXR ... intake ignores most all factory packaging considerations to provide stunning performance."

The BXR is no longer manufactured and I am not a representative of that company. If you need information beyond what you see here, you may find it on this mirror of their old website. If you want to purchase a BXR look on used auto part sites or ebay.

There were three different plenum covers you could choose for the BXR manifold. I choose the hi-torque plenum covers for my Mustang because it was a daily driver and I thought I'd buy the other kinds later. It's interesting being able to inspect the inside of the manifold with just the removal of a three bolts, but the real utility is in the easy of switching covers and transforming the characteristics of the engine. Also, porting and polishing is much easier with removable covers. One thing about the  hi-torque covers and the manifold was it seemed to produce more power at slightly higher RPMs than stock. If you babied the throttle it felt less powerful than stock, but if you got on it, you felt the difference.

Some general advice on installing a BXR.

• Check the engine's computer for error codes (or trouble codes) before you begin.
• If you have aftermarket fuel injectors get the special rails. The fuel rails that came with the manifold kit worked best with stock injectors. There were larger o-rings in the special kit which I needed for my 30 lb. hr. fuel injectors.
• Plan for the extra forward height of the manifold. You'll need more room in the front, so if you have a hood mounted functional ram air kit, it will be in the way. The manifold fits under a stock hood, but there's no extra room.
• Have a crows foot wrench and lots of patience for installing the temperature sensor on the manifold. There's not enough room to work and the manifold is alluminum. You might want to consider a temperature sensor relocation kit. I didn't and I had a difficult time getting it seated so that it was sealed but didn't interfear with the fuel rails.
• Get diagrams of hoses and wires or make sketches before you take it apart.
• Use the fan relocator kit if you have a stock fan and radiator. The clearance looks fine at low RPM, but when you rev the engine, it'll jump forward and the fan will attack the raditor.
• The throttle linkage on the BXR isn't clearly explained in the instructions, so I've taken a picture of how it looks installed.

The microS Way

As a conclusion to my notes and reflections on the CA Microservices Conference, I wanted to share the MicroS Way that was presented there.

1. Establish the right boundaries in your code and organization

2. Have a system that balances easy and speed with safety

3. Have the right processes and standards

4. Steer the system and measure it

5. Accept that right, easy, and safe are a product of time and context

MicroS - lessons learned part 3

This is a continuation on my notes from (and reflections on) the CA conference on microservices.

How to Change

Use shock and awe to make change. Be a little outrageous. Do not pivot by spinning on your heel --sprint with a two-by-four, slam it in the ground, and spin round to a new direction. An enterprise is about maintaining stability, so it won't change just because you casually mention it. You need to prove this change is happening and motivate the teams. Have a crazy challenge motivator.

And make the rules of change embody your bold statement. For instance, Gilt moved to microservices by saying you cannot use the main database or commit to the Ruby on Rails depo. These two rules helped to build a completely autonomous system. The trick is to find something simple that forces a new direction.

Besides changing the technology focus, change the way you frame the problem. Gilt doesn't say "do this" but instead gets the best out of a team by asking, "how do you solve this?" You want to tell your team where you are headed, but not how to get there. This is partly because it encourages inguinity, but also because the people on the ground floor always have great knowledge of how things work. Even if management rises from within things can change and those that know the day-to-day need to be consulted.

Another way to get the best out of a team is to have the right team skills. Agile teaches that you put the key players on the team. You choose the engineers and developers that have the skills for the software and technology that you need. The expertise is built within the team so they don't have to reach out and wait for someone outside the team to have the time to help. But there's an expertise that can be overlooked in the team: the business. Having close allignment with the business is automatic when someone with business background sits as a member of the team. Furthermore that person will gain an understanding of the pressures on IT so that the whole team can make wise decisions on what is both business valuable, but not shortsighted of long term IT cost.

Part of long term IT cost is the fact that once something exists it seems to be able to justify its continued existence based only on the fact that it exists. "Someone might need it" justifies going to large cost to maintain an unnecessary system, while half of that cost will not be spent to build a necessary system if it does not exist yet. There are very human reasons for thinking this way that all of us are prone to. The way to combat this natural tendency is to have a Sunset Team. This team is charged with responsibily shutting down systems that are no longer needed. The entire organization should celebrate shutting down an old service as much as they celebrate a new one.


Building Teams

It can sound easy to just put together a team, but there is a lot to consider. Besides what I already spoke to about having the right skills on the team there is also attitude and size to consider. At the conference a team size of four to five people and a department size of around 20 was recommended. If you do not have at least ten engineers working on microS, then your group likely won't be able to handle the increased overhead that comes with microS. As for choosing the people watch how they naturally gravitate to each other. For instance, watch for those that want to work on the new and shiny stuff versus those that want to build a solid infrastructure that is hardened. Put them in separate teams and give them the projects that fit them best.

But do not build new teams and ask them to build microS right from the start. The team should always better understand the work than the technology. In other words you can be new to building a shopping cart, but you better be experienced in building websites and never vice-versa. Your first microS should be ones that you build to solve a business problem that your team already understands. Always know the business better than the technology.

One reason for knowing the technology better than the business is that debugging is always more difficult with something you do not know. This is especially true of microS, but true of anything. If you know the business part well you at least have a firm understanding of what going right means even if you don't know why something is going wrong when a bug emerges.

Focus on team culture. Change that goes against the culture will not be lasting and likely will not even take place. It is an attitude challenge. Culture can cause a team that always codes in Java to write Python as if it were Java. Changing technology does not change culture. Over time a balance will grow in a group between culture, technology, and structure. When you change one the balance is lost, but the group will try to find the balance they once knew by modifying the other two to make up for the change in the one. Unless of course the change to all three is thought out and the team is properly prepared for it.

You properly prepare by knowing that these three steps must happen in this order:

1. The technology and culture is stabilized. Things in flux are actually less able to change because everyone recognizes that the last thing you want to do with a shaky house is change the foundation.

2. Optimize them. Once you have stabilized you can build on that and have a better system, which helps motivate the team to believe in their ability to create effective change.

3. Transform them. Now you are ready for real change.


Embrace Change and Risk

I wrote in a previous post about how to talk about failure. Netflix has a great culture that embraces this at all levels. The fact that they can openly talk about Quickster proves they understand that innovation comes with risk and the best way to learn from it is to talk about it openly. They trade lessons learned in an open way, which transfers knowledge between teams in a radically better way than in a workplace where competition means not admitting what went wrong or could have been better.

MicroS - lessons learned part 2

At the CA Microservices Conference, Vijay Alagarasan spoke about some anti-patterns. I have reworded them to be patterns to follow and added a couple of my own thoughts.


Automation is Litmus

The litmus test on whether you can handle microS is if you can automate. Automated testing and deployment is key to microS, but beyond that if what you have is not regular enough or so eccentric that automation is not possible then you either still in R&D land or you simply are not ready yet. You do not need to automate everything, but if there is something about the software that inhibits automation then that will be a problem for stability, scale, or your own sanity when problems occur.


Centrally Manage Config

Design a configuration manger. There should be one server (not literally one, you're allowed redundancy) that can send configuration changes to your services. If you don't start from day one then you will be unable to control scale. The time to centrally manage the configuration of a service is when you deploy the first instance. Once you are running 15 instances of it, you are likely to miss an instance when you need to change a setting on it. Just think to the last time you were debugging an issue that was intermittent and you checked everything only to finally discover that one of the servers was configured differently. Sometimes it is obvious, but given that you always assume someone was diligent and set them all up identically you can often overlook that sort of bug. Avoid the headache and always manage configuration centrally.

The one argument you can make against central config is security. As I write this it does occur to me that a malicious actor who merely wanted to reek havoc on your network could do it through the config server, but that is more the case of a disgruntled employee with system knowledge. Chances are your hack is going to be by someone that wants to find their way to something valuable and changing something like a rate limit on an API is not likely to help much. Maybe talk to your security officer about this if you are concerned.


API Gateway

An API Gateway has many benefits. It can reveal a lot about network traffic and help to control it with things like caching, routing, throttling (limiting particular calls), and authorization. It can also help you transition from one version of a service to a another by slowly moving traffic to the new one. For example: consumer A is routed to version 2, but all other consumers are routed to version 1. Then consumer B moves to version 2 and so on. A good version strategy allows you to to introduce new versions of a service with a minimum of risk.

However all of the stability a gateway can offer can be reversed through misuse. Every bit of business logic that works its way into the gateway is a potential production issue. The point of the gateway is to abstract you from the business logic so that you can change your business logic carefully (as mentioned with transitioning to a new version of a service). If the business logic is in the gateway then you cannot change that logic without risking all of your traffic being negatively impacted. There will be some business logic in your gateway, but assume anything you put in there may need to be changed and cause a full system outage. Each IF statement should be put in place with that realization.

I'm unfamiliar with these products, but CA Layer 7 and AWS Mobile Gatway are examples of API Gateways.


Question Every Layer

Abstraction is a useful tool, but it needs to be used purposefully. For instance, having a policy to abstract the connection to every database is not good. Each use of abstraction should be for a strong reason about that particular case. Unnecessary layers should be avoided. A coworker told me "no one ever wants to be the middle man" and you should think of layers like middle men. Most of the objections to middle men are the same reason you don't want extra layers in your software. They introduce complexity and the potential for translation issues, they constrain your message into their terms (admitidly this can be a pro), and they consume resources. People would always rather go to the source, but they will put up for a middle man when there's a good reason. Don't just have an extra layer in place like in Office Space.

Do not separate your layers by bussiness logic, data access, or orchestration. One layer should likely embrace all three of these things. The boundaries of a service should be based on a business solution and not a technical one. You are building services to solve business needs. Being able to switch your database out to another one should not be the guiding star by which you design your services. If you have a good version strategy then that should be all you need for technical changes.

Microservices (microS) - lessons learned part 1

This is a continuation on what I learned from the API Academy's microservices conference. None of these are rules, they are all principles. My personal belief is that the only rule should be to embrace continuous improvement.


wAgile

Holger Reinhardt introduced the concept of wAgile which is a blend of waterfall and agile. On the one hand this sounds like an oxymoron and certainly there were laughs at the term. (A colleague of mine suggested perhaps watgile for WATerfall aGILE would be more successful as a term.) If you consider however how the triad of thesis, antithesis, synthesis works of history works though it makes sense.

The industry started with waterfall which is great for project management and it helps managers place timelines, staffing, and schedules of other projects, but waterfall has the danger of mapping things out in such detail and so far into the future that by the time you get to the end of the project you find it fell victim to the rapid pace of change of technology and business, which did not respect your careful planning. A well planed and executed project that solves a problem that no longer exists is sadly as much a failure as a disorganized one that couldn't even complete.

There have been various solutions to this, but agile is the recent darling of the industry. For startup culture the focus on MVP (minimum viable product), which gives early results means you begin to learn and adapt to your market rapidly. Not having a timeline of more than a few weeks out is fine for a company which isn't entirely sure what the business will be by then. Removing the long term calendar and only deciding on when you will complete the next task vastly increases the accuracy of a developer or engineer's time estimates.

In agile training I picked up the razor for separating a candidate for waterfall from agile, which is to ask where the unknowns are. If you know your technology well and know the business problem well then you can probably have a very successful waterfall project. Waterfall depends on your ability to predict and if you have previous experience that applies to all aspects of the project then you should be able to reasonably predict. However if you are building a new business model with new technology then you will do better with agile.

In the enterprise world though things are rarely so clear. To balance innovation with safety you are likely introducing new technology carefully and not all at once, so it is a partial unknown. The same goes for the business which tends to solve problems with mostly familiar solutions and doesn't jump into completely unknown markets in big ways. Also my experience is that no one likes to hear "we'll be done when we are done."

What wAgile says is do the planning and accept the unknown. You do that with the old trick of padding the schedule, but you do it in a smarter way. If you pad each task or phase on a Gantt chart then invariably the time will get used. If someone is done early they likely have pressures on them to get other work done for the business and they will do that work. Yes, it is time spent productively, but it is not helping to get the project done.

Instead of padding parts within the schedule, Holger says, you pad the entire schedule at the end. Keep every task or part tight without any extra time and try to stick to that. When the inevitable happens though and something does not work as planned or the time allocated was simply not enough then take some time out of the padding at the end of the schedule.


New Technology

How do you keep current with new technology and have standards? On the one hand you want to pick a few tools and make those the standard so everyone can know them well and technology can be reused or repurposed easily. Yet this closes the door on introducing new technology and keeping current.

Gilt does this by having an architecture board that brings various groups together to talk about what works and what doesn't. They celebrate when you try and fail (more on that below), because that is how you learn and you cannot innovate without trying new things. The process is to drive consensus on the standards.

There was support at the conference for what I believe is also Amazon's take on this. The policy should be if you adhere to standards you can expect full support. So things like monitoring, off hours support staff, production hardened environments, and infrastructure automation are all available to you. However if you want to code in a new language then all bets are off. If the system crashes at 3 AM you take the phone call and fix it. Sure your colleagues may help you, but you cannot expect it and you certainly cannot complain.

This not only is a policy that allows the introduction of new technology, it is also a policy for retaining key talent. Teams often have a mix of those who constantly play with the latest tech and those who hone their craft on their current skills, but the former will be discouraged if there are no opportunities to use the new tech in their jobs.

When evaluating new technology have metrics on the new and old. If new technology is a narrow improvement then be skeptical. There is a lot of overheard in learning new technology and implementing it which has to be outweighed by the improvement.

I cannot speak to how useful it is, but a few people said that Thought Works' Tech Radar is a good start to conversations on new technology.


How to Talk about Failure

A blameless postmortem is pointless. You need to learn from mistakes, but you need to also accept that everyone is human and mistakes happen. Pointing fingers is not helpful. People need to be encouraged to feel comfortable saying, "it was me, I broke it, and here's how I fixed it." A good programer is one who knows how to recover well from a failure. A programer who hasn't had failures is lucky and lacks that experience needed to handle that inevitable failure when it happens. This is what is at the heart of the concept of "fail quickly" which assumes you will recover quickly. You can only do this in an environment where failure can be discussed openly.

Microservices (or microS) - overview

The API Academy hosted a conference on microservices in Manhattan. I only stayed for the morning due to a busy schedule for myself that afternoon, but I was impressed. When a presentation includes pros and cons or includes stories of what went wrong I regard it as honest (more on that in my next post). A flawless IT project or technology is a rare thing and probably more about luck than skill. If you are solving a challenging problem with new tools then things will go wrong. I have always felt the mark of professionalism is not avoiding problems, but quickly recovering from them. (When you only seek to avoid problems then you stop innovating.)

What follows is what I learned from the conference about microS along with some of my own thinking. The presenters of the conference are owed credit to the good ideas, and the mistaken and flawed should be credited to me.

To cut down on typing and just because I like it, I'm going to refer to microservices as microS from now on.

Why microS?
As we have embraced SOA (Service Oriented Archetecture) we now have a mess of confusion on the network. Just as when the automobile first hit the road, it was fine when you just had a few cars, but once everyone had a car on the road there was chaos and traffic rules needed to be introduced. It is not sustainable to blindly create a service whenever there is a need if you lack an overall structure and plan. The hope is that microS give you "speed, safety, and scale in harmony" which is what the highway system, DOT, traffic regulations, and traffic conventions brough to the roadway.

What are microS?
As an evolving buzzword about an evolving concept it is difficult to define. The discussion seems to be centered around the concepts in the image below. Everyone's definition is basically a collection of a handful of these concepts. (ignore that small is highlighted)

A word about small: microS are not as their name suggests all about size. It is more about thoughtfully setting boundaries. If you divide up your services based on rules such as "it's a different service each time a different system is involved" or "it's a different service each time it's a different dev team" then you are setting boundaries based on an irrelevant thing. Set the boundaries based on what the software is doing. Systems suffer when the service size is made too small (often caused by trying to abstract and layer everything, which ironically makes change difficult) and they suffer when the service size is too large.

Another misconception that microS are trying to fight is the urge to not repeat code. Multiple version of the same thing are not only acceptable but encouraged. MicroS are trying to manage change. The desire to have, for instance, just one search engine might be making change management intolerable. If having your HR system and product system share a search engine results in exponential complexity then don't solve search with just one service. Build a service, clone it, and have two.

Startups vs. Endups - speed vs. safety
When you are a startup you can afford to be less safe and you can be like Facebook and declare that you are going to "move fast and break things." But as you grow stability becomes part of the business model and even Facebook finds itself with a less sexy slogan like "move fast with stable infrastructure." Endups (established businesses) need to balance speed and safety. MicroS exist in this space where they are not like monolith system design where safety requires a very slow pace of change and they are not like the constantly updating system that 10 developers can maintain in a startup mode.

For instance one difference is that unlike at a startup where you might edit code directly in production you do not edit production code in microS. However unlike in a monolith culture where you need sign off from lots of parties and full system testing, with microS you have automated testing which allows you to safely push your code live without that beaurorcrasy in the way. It is a balance.

The MicroS Way
Rather than define what microS are we can define what it looks like when you have the right environment for them:

1. establish the right boundaries (size) in code and your organization (developers and business people)
2. balance safety with ease of change in the system
3. have the right processes and standards (more on this in my next blog post)
4. steer the system (from a high level) and measure it (data driven)
5. accept this: right, easy, and safe are a product of time and context

The word you see continually is "balance" and when you think of the old monolith design (one huge system that ran everything) contrasted with the small individualized world of SOA, what microS offers is a balance between the two. We will also see this in my next post in the concept of wAgile (waterfall agile) which attempts to balance the approaches.

Drive

https://www.youtube.com/watch?v=u6XAPnuFjJc

Holacracy - notes from a taster workshop

Instead of structuring a company around the people, as we do in traditional management hierarchy, holacracy says you should structure the company around the work that the company needs to do to express its purpose.

If there is nothing that makes you skeptical about holacracy then you're probably missing something. It is a radical shift from traditional management hierarchy.

Holacarcy is a replacement, not something that can be added or incorporated within traditional hierarchies.

One of the ways holacracy encourages process improvement is that it acts as a mindfulness exercise for the whole organization.

Traditional management hierarchy is the unconscious choice of business. You should at least consider if it was the correct choice.

In holacracy power is not held by a CEO -- all power rests in the constitution (which itself is a definition of the process). The way you enter into holacracy is by the CEO ceding all of their power, much like the way in history kings would decide to dissolve a monarchy for a new system like democracy. There are a lot of interesting observations to be made about holacracy and traditional management hierarchy when comparing the strengths and weaknesses of a monarchy versus a constitutional democracy.

While you might expect diffusion of responsibility as a result of placing power into groups, there is actually a structure to who makes which decisions. There are point people who have specific responsibilities. Who are those people? Everyone decides that as part of the process.

The most unintuitive thing for me about holacracy is that even though there is a huge focus on autonomy, there is actually a lot of highly structured process. It is not anarchy. What one could say is that instead of using the unspoken rules of politics and power dynamics, holacracy asks you to make all of the rules transparent and gives you the power to change those rules in order to make the business function better.

Another common misunderstanding is to think that without hierarchy you do not have structure. There is a well defined structure in holacracy which places everyone into circles. A circle is a group of people based on a part of the work that needs to be done. In a small company you would have a finance, marketing, advertising  and other circles that roughly correspond to departments of today. However in a large company you would have many circles that handled finance activity. A circle (much like a meeting) really can't function well once it starts growing above a dozen people. Once circles get too large they should be divided in two -- much like a cell dividing in an animal.

Each circle in a company defines someone as the "lead link". This is a position that can rotate and acts as a liaison to other circles. The lead link also has the responsibility of speaking for people who are unable to attend meetings.

Speaking of cells in animals, to continue the metaphor for holacracy circles,  every circle is a cell and even though there is no boss or master cell that tells the other cells what to do, cells organize as organs and then as animals and are fully functioning. What is nice about his model is that it explains how a really large organization can remain as flexible and adaptive as when it was a small organization.

There is no one definition for how to fire people in Holacracy. One company handles it by having a circle responsible for it. If you are honest about it though the traditional system does not have a great solution -- it is always a difficult thing. What holacracy does say is that you should define your process and that's an important thing. We often leave difficult things vague, but holacracy gives you a tool and responsibility for defining the process.

Another difficult topic can be compensation. How much should you pay employees should be something you have a defined policy for and holacracy again asks that you figure that out for yourself. There are "apps" in holacracy which are basically optional add-ins to the process and there is an app for compensation.

Of course one consideration in firing people and compensation is employment law. One way to avoid this is to declare that everyone in the company is a partner (they have a K1 not a W2). This way there are no employees, just partners. While this is how Holacracy One handles the challenge, it has yet to be tested in court.

Normally in a status meeting how much you say is inversely proportional to how much you got done. If you're done you just list what is complete. If you are not done you spend a lot of time explaining the reasons you are not done. Unless you are asking for a solution to what keeps you from finishing, this process is a waist of time. This is why in holacracy you say "done" or "not done" at a status meeting which saves a lot of time.

Holacracy starts by empowering everyone equally. Instead of saying here is a small set of things you can do, it says we are all empowered to handle whatever needs doing. Before we run straight into chaos with that though we do define some requirements of certain people and do place some constraints on who can do what. This is an evolved process however and everyone has the ability to call the requirements and constraints into question and the expectation is that they will change a lot at first. The advantage is that there is a built in system for process improvement. Holacracy may start out worse than traditional systems, but because it can evolve through process improvement it allows an organization to constantly get better. A traditional system tends to live with its problems and consider them facts of life instead of solvable things.

We are not always asked to be self actualized people. We grow up in a hierarchy of parents, teachers, and various authority figures. Breaking from our parents and becoming adults is a difficult process, but it is not always a complete process. Some people jump from that straight to having a boss and never learn to be their own person. It is difficult to do this, but it makes for better psychological health and in holacracy better employees. The great difficulty it takes for individuals to do this underscores the challenge in transitioning from traditional management hierarchy to holacracy.

The process for integrative decision making is very structured. It has the following steps:

0. Before the process begins everyone goes around the room and voices what is bothering them. This can be something that is irrelevant to the meeting, like "my shoulder hurts" or something like "I don't want to be here -- I have a fire that I need to put out." The idea is that we all have things that are distracting us from being present and the mere act of voicing them can silence them in our minds and allow us to focus.

1. present proposal - At this time only the presenter speaks. The proposal is captured and displayed so everyone can see it.

2. clarifying questions - The participants may ask questions of the presenter, but they can only get data out of the presenter. They will be silenced if they are trying to voice their opinion or influence the presenter to change the proposal. It is just for understanding the proposal.

3. reactions - Each participant gets a moment to speak honestly about what they think of the proposal. There is no discussion -- each person takes a turn and should be speaking independently. The idea here (much like step zero) is that we can feel compelled to voice certain opinions, but sometimes all we really want is to get the idea off our chest. It acknowledges that we are emotional creatures and gives us a chance to succumb momentarily to the emotions so we can then move on and get something done.

4. amend/clarify - The presenter is allowed to change the proposal at this time. This is not allowed in the previous steps because that would let the participants quibble about wording and get into an endless wordsmithing exercise. The point is not to have an eloquent or perfect proposal, but instead to have something that works. So at this time the presenter may choose to change the proposal based on the input up to this point. Only the presenter speaks during this step.

5. objection round - Each participant is asked if they have an objection or no objection. If they say they object then there is a highly structured way of dealing with those objections.
* If you object because you have a concern, then you are asked if that concern is something known or an assumption. We often voice concerns as if they are known facts when they are actually just something we fear will happen. It is important to be honest whether the objection is fact or assumption. 
* If the objection is an assumption then the question is if that is true would that be something we can adapt to later and fix. If we can adapt and rectify the issue then it's not really and issue. Knowing that we are in a system of process improvement we know mistakes will be fixed. Of course some risks are of things you could never repair and if that is the case then it is a valid objection.
* Another way to judge the validity of an objection is whether the objection is about something not directly related to the proposal. For instance if I needed an assistant and the proposal was to spend more money I might object to the proposal because it would take away money that could otherwise go to highering an assistant for me. When I voiced that objection I would be asked if my concern would still exist even if the proposal was not on the table. Since I still need an assistant regardless of the proposal, the objection is not valid.
* Holacracy does a good job of finding solutions by keeping a sharp focus on the question at hand and not allowing everyone's concerns to muddy the conversation.

6. integration - If there are no objections then the proposal is carried out. If there are objections then step 4 and 5 are repeated until the proposal is carried out or withdrawn.


Since I think invalidating objections is a really important part of the process, here are some more examples:

-- "Is that objection based on a concern you are feeling that would still be there if the proposal didn't happen?"
-- "Yes."
-- "Then that's not a valid objection."

-- "Is there any reason this proposal would hurt the company or our way forward? If not then it is not a valid objection."


What I called a "concern" above is referred to in holacracy as a "tension" which can refer to concerns, but also interpersonal tensions and it extends to what you might call a "difficulty". In traditional hierarchical management tension is not handled well. We tend to avoid dealing with tension and do our best to steer clear of it because it is difficult and often has political implications. In my experience tension resolution only comes from a person of power dictating something which tends to create new tensions. However instead of tension resolution we usually ignore the problem or make decisions that make no sense except that they allow us to work around the tension.

Resolving tension is hard work. It is not easy and it can be awkward and uncomfortable. That is just a reality of any system; however, holacracy gives you tools like the integrative decision making process that allow you to dehumanize the process and find real solutions. The idea is that it will be hard, but as you repeatedly address tensions you will get better and better at it and soon find you are solving tensions instead of avoiding them.


Instead of saying "I'm too busy" the thing you should say is "that's not a priority to me." Maybe there is a need for a discussion on the priorities, but there is always a lot of work to do and we can be very busy but not doing anything important. We should stay focused on the idea that we need to work on priorities. Having autonomy empowers people to do that.


If there is a conflict (disagreement) over priorities then the "lead link" (a special role in holacracy, see above) makes the decision. For the long term though there is a process of governance that lets you set requirements of people.


We get in our way so often in our own organizations by trying to be smart or clever. Our minds are not always our friends. We say things in meetings for this reason and we are not adding much value to the actual work that needs to get done. This is especially true in policy formation. The idea is do something, learn from it, adapt. You'll wind up with something that works well because it is based on the real world and not how clever you are.


The above was from my experience at the Holacracy Taster Workshop and much of what is above comes directly from what Brian Robertson (the primary developer of holacracy) said at the workshop. 

Agile Scrum - a few important points

Empirical process control says we should observe what happens in the world, learn from that, apply the knowledge, and repeat the cycle.

In generic terms: Plan --> Do --> Asses (test) --> Act (adapt) --> repeat

In Agile Scrum terms: Adapt --> Scrum --> Inspect --> Scrum --> repeat

At the center of both of these cycles is transparency.

What can be useful is to send a tracer through the concept. A tracer is like a tracer bullet -- it is something that can mover through all of the complexity of your process and be seen within each step.

Build / Run

The build / run concept says have one team totally focused on new development (build) and one team totally focused on operational issues, help, day-to-day (run). The problem with this is that most developers want to be on the build team and the run team doesn't encourage growth. The solution is to rotate members in and out of both teams. Being on the run team should always be a temporary condition.

When does the traditional waterfall method work?

1. when you are working with known technology

2. when the components are stable and standardized

3. when the requirements are complete and unchanging

4. when the process is highly repeatable (you do it a lot)

Velocity

In agile scrum velocity means the average number of story points divided by sprints. In other words: on average how many stories do you cover per sprint?

Refactoring

Rewriting code without changing the functionality. This lets you clean up the inefficient code that results from constantly adding new functionality. It allows the developer to redesign without input from the business as the functionality must remain the same. "Rework is better than no work"

User Stories

The 3Cs of user stories:

Card - the story should fit on an index card

Conversation - the story is a commitment to a conversation/negotiation

Confirmation - you need to know the acceptance criteria for the solution

Color

Here are a couple references on color. Copyright info is within the images.

Adobe Conference

Recently I attended a conference from Adobe about Creative Cloud and marketing. Although there were more presentations, I found the first three most interesting. Here are my notes with some photos of the presentation.

1. Debbie Millman

Branding = deliberate differentiation 

Human beings metabolize everything quickly. We see this literally with food, but metaphorically with love and with the delight from new products. Being the first on the block with the newest product is temporary and equally fleeting is the joy that aspect brings.

The inward isolation of the iPod has been replaced by the virtual connectedness of social media and this represents a complete change in marketing.

The next wave of product management and advertising is in managing the anxiety of measuring ourselves and our connections.

In today's world if you want to succeed focus on giving the consumer these three things: connection, purpose, fulfillment

Limbic branding - brands as connectors

Have a focused message and don't completely change it for multiple audiences or locals. Do not be ambiguous. We always perceive ambiguity negatively.

---

2. Ashley Still - Creative cloud

Connected assets allow assets to sync and remix across apps

Experience manager assets - central content storage - connects design with marketing

---

3. Scott Belsky 

This is both a good thing and a bad thing. We need time to concentrate on the ideas that should happen.

Organization with a bias to action. Write with verbs. If nothing actionable comes out of a meeting then you didn't need it. There should be follow ups. Leaders often write reminders to themselves of "ensure this" and "ensure that". Prioritize projects visually -- use an energy line. Compromise and put some things at low energy -- if everything is at high there's no point in having a line.

Work with what's working and keep optimizing. Never say "if it ain't broke don't fix it".

Share ideas liberally and don't worry about them being taken away. You'll receive far more necessary input than stealing of ideas. For instance share ideas in a blog and then take of with the ones that seem to have an impact on readers.

Seek competition - drive comes from seeing another doing the same thin, which makes you want to do it better.

Great creative teams fight a lot.

Fight apathy as well. Don't let people check out and give up the fight.

Leaders talk last. If you start a meeting with "Here's what I think, what do you think?" then that won't engage others. Don't make them try to find an idea that's similar to yours. First allow for input from others

Value the immune system of the team. The doers will fight off something new. Once in a while suppress it for the dreamers to bring in a new idea. Be the bureaucracy breaker - try to keep moving even if it is inch by inch.

Make people (even your bosses) make decisions.

Gain confidence from doubt.

How to discover a server's mail relay

On Solaris 10 run the following command as a regular user:

grep rhmailer /etc/mail/sendmail.cf

On RedHat/Centos 5 and 6, first discover the OS release level:

cat /etc/redhat-release 

For redhat or centos 5 run the following command:

grep rhmail /etc/mail/sendmail.cf

For redhat or centos 6 run the following command:

grep rhmailer /etc/postfix/main.cf

Opening large files with Oracle SQL Developer

Oracle SQL Developer is my go to SQL tool. It is powerful, easy to use, and free. The only issue is that it can easily produce SQL files that are larger than it can open. For instance if you want to quickly back up a table, you can just run an export in "insert" format and it builds all the insert statements for you. Trouble is if that file's over around 30 MB you can't open it. The issue is that this is a Java program and the space allocated to the JVM at startup isn't large enough for big files. The way to handle this is to increase the memory available to the JVM. Keep in mind when doing this that your OS may limit how much actually gets allocated and of course you could hit a hardware ceiling. So just because you can type a huge number in the configuration file, doesn't necessarily mean you'll get that much memory. Otherwise though this is a simple change that works well.

What you need to do is find the sqldeveloper.conf file. You can just do a search on your system, though keep in mind that some systems (like Mac OS) consider this a system file and don't expose it in the GUI. You may need to use a command line to run your search.

On a Mac you'll likely find the file here: /Applications/SQLDeveloper.app/Contents/Resources/sqldeveloper/sqldeveloper/bin/sqldeveloper.conf

Just open a terminal, use your regular UNIX editor and open the file. Add this line to the file:

AddVMOption  -Xmx2048M

If you find you still can't open your file and that you have more resources available, increase that number until the file opens. Do pay attention to system resources though and leave some memory available for the OS and other apps.

Our Home Made Sukkah

We've always lived in apartments and until this year didn't have private outdoor space where we could build a sukkah. Our current apartment though has a balcony and even before we were sure we wanted to rent the apartment, we were sure that if we did, we would build a sukkah on the balcony.

So a few weeks back I started. I have never built a sukkah and only been in a handful of them. As I sometimes do though I got a few ideas in my head.

One was that the walls should be canvas (because regardless of the truth that seems authentic to me). Another was that the frame should be metal (because it should be strong). And the other notion was that I should build it on my own outside.

My wife did a little research online and found one or two useful articles. The first one sounded good, but it lacked details, so in some ways this is my adding that detail. Also please take note that if you are strict about things, this is NOT a Kosher sukkah.

Also very important: I have no idea what I'm doing.

I am not a trained professional sukkah builder. This may not be a safe sukkah. This may not be legal in your town to have it on a balcony. Also you may be overrun with ushpizin because it's such an amazing sukkah. In short: follow my example/instructions at your own risk. I make no claims as to the safety of this process or sukkah.

Materials

1 package of 50 to 100 safety pins
10' to 15' #600 galvanized 18 ga wire
2  12' x 15' canvas drop cloth (actual dimensions are a bit smaller)
0 to 4  1" gas pipe floor flange (optional depending on location)
16  3/4" xclose gas pipe nipple (it's like a piece of 2" pipe that's fully threaded)
4  3/4" galvanized gas pipe tee
4  3/4" galvanized gas pipe 90 degree elbow
8  1" x 10' galvanized electrical conduit pipe
10' nylon string
10 - 12 screws
8 to 16 zip ties (3/16" or larger)
2  10/5' long 2x4s (I didn't use these, but should have had something like them)
suchach (sized to be larger than the top of the sukkah)

( ' = feet; " = inches)

Some of the needed materials:
conduit, floor flange, tees, elbows, and nipples

Tools

Pipe wrench

Vice (I used a #4, but anywhere around that size will do and you could make do with 2 pipe wrenches instead)

Drill w/ various bits

Pipe cutter capable of cutting 1" pipe

1 or 2 old rags

Rotary tool with grinding stone (I used a Dremel)

Wire brush
Center punch (optional)
Hammer
Oil paint marker (optional)
Scissors (for cutting canvas)

Preparation

The first thing to do is cut the pipe. Our balcony has a metal railing which I wanted to tether as much of the sukkah to the railing as possible. Since the balcony is 80" by 140" and the pipe is 120" long I decided to make the sukkah about 80" x 120" which seats 6 comfortably or 8 snuggly.

For the height I decided on around 6.5' since the drop cloth was 15' on its longest side. Half that and allow for a little bit of extra to wrap around the poles and the maximum you can do is around 6.5'.

So I cut 6 of the 8 pipes to those sizes (2 of them were already properly sized at 10'). Keep a bit of the scrap pipe handy as you'll need it in the next step.

the four corners

The next thing to do is build the corners. Take the tees and elbows and put them together using the nipples. The nipples are slightly cone shaped, so as you tighten them they become even more tight. I did the basic assembly, then used a vice to tighten them up all the way. I put some old tee shirts around the galvanized parts to protect them in the vice (see picture below). Also, in the vice I put the pipe wrench on the elbow and the scrap pipe on the wrench for some extra leverage because you really want to be sure these connections are tight. I made sure I had two sets of corners that would work for the left and right side as shown below. It's important that the elbows are 90 degrees spun from the bottom of the tee as this will keep your frame square.

Once you have four corners like the ones above take the remaining nipples and put them into all of the ends. You can put a pipe wrench directly on the threads without worry of damaging them because we'll be removing those threads later.

adding the first exterior nipple
(the vice is wrapped in an old tee shirt)

tightening the second exterior nipple

completed corners

grinding the threads off the nipples

The next step is to grind the nipples down so the pipe fits on to them. Somehow I thought I'd picked the perfect size that the pipe would just screw on to the nipples, but I must have gotten confused in the hardware store as that didn't work at home, so I pulled out my dremel and a grinding stone and removed the tops of the threads (and smoothed out any marring from the pipe wrench). Basically I ground the nipples down until they fit nicely in the pipes. The whole process used up one new grinding stone.

Once the nipples were done I removed the burs and hanging bits of metal from the threads with a wire brush.

cleaning up the nipple with a wire brush

fitting the pipe onto the nipple

The next step is to drill holes into the pipes and corner pieces, so you can secure them. A punch always helps drilling (especially with a curved surface like a pipe). Be sure that you drill so that the screw goes into the middle of the exposed part of the nipple. I used metal screws with hex tops because I figured they may rust and be difficult to get out (the nipples aren't galvanized). Do this for the full rectangular shape of the top of the sukkah. Disassemble after building the full frame though because unless you have help you'll want to build this in a set order.

above secure screw in place
below drilled hole ready for the screw

To be sure everything would fit together easily, I used an oil paint marker to put numbers on all of the connections between pipe and nipple so I could always match pipe 1 to nipple 1 and 2 to 2. Unless you're perfect with the grinding and drilling you'll likely end up with parts that aren't fully interchangeable, so this keeps that from being a problem.

Now it's time to assemble the frame. First build a short side by putting two corners on a pipe. Remember that each tee should have a nipple facing down for one of the vertical pipes to go in. It should look something like this:

pipe with two corners attached
(and all the scrap pipe pilled to the left)

Now attach another side of the top to the parts you just assembled and then put a corner on that pipe. You should have three corners and two pipes all with the securing screws in place. At this point you've assemble a little over half of what will be the roof.

corner with two top pieces of pipe

Grab one of the pipes that will become a vertical part of the wall (a leg) and put it into a tee so that all nipples on one of the corners have pipe in them.

at this point things get a little wobbly

While holding the assembled parts up with one hand, put a leg on the other corner. With both legs in place, you'll have them and the one top pipe on the ground and it won't be so wobble (for now).

putting the second leg in

Grab the top pipe that's resting on the ground and raise it up. Put one of the legs into the tee on the corner that had been on the ground. Although not very stable you have three legs at this point and it should stand. This is where having the railing on the balcony is great because you can use the zip ties to hold the pipes in place. Be sure to move the frame to where you want it to end up before zip tying it. Put at least one zip tie at the top of the rail and one at the bottom. Add more for a little extra stability.

zip tied leg

I don't have pictures for the next couple steps, but hopefully it's intuitive. Attach another top pipe to one of the standing corners. (Always put the securing screws in place the moment you put a pipe on a nipple.)

While holding that pipe with one arm to support it, attach the last corner, and then put the leg on it. Now you have just one more top pipe to put in place. Because there's some give to the frame you should be able to pull it apart a little, place the pipe into the nipple, and then pull it shut. Hopefully you have a frame like this:

For me I was able to secure 3 legs to the railing, but the last one had nothing to be secured to, so I put a 1" floor flange on it. This should just screw into place onto the leg and give it a little more stability, but mainly keep it from digging into the surface of the balcony too much.

leg with floor flange

Now it's time to secure the legs with screws in the same way that the top pipes all have securing screws. Since the one leg was free floating I put a level on it to be sure I was attaching it at a right angle. I chose to only put securing screws on two legs (at opposite corners), but putting a screw on each leg is probably smart.

assembled corner with painted connection points
(A goes to A) and securing screws all in place

Check that all of the securing screws are tight and the frame feels solid. It should give a little, but not much.

Now it's time to make walls. Take the drop cloth and fold it over along the 15' side (hopefully you can clear a space big enough for this). Cut along the fold line and you will end up with two equally sized roughly 7' x 10' pieces of canvas. Repeat this on the second drop cloth and you'll have 4 identically sized pieces.

Hopefully you can find a time with no wind to put the canvas on. Decide where you want the door to start and make that where you start with the canvas. Wrap the canvas around a top part of the frame (not a leg) so that the cut side is parallel to the pipe (and ground). Start securing the canvas with safety pins.

One thing that helps this process is to take the far end of the canvas and drape it over the top of the frame. This makes it so not all of the weight of the canvas is on the section you're trying to secure.

Work your way around the top of the frame securing the canvas. A safety pin every 4" or so seemed to work well. When you have one piece secure, put another piece on, but overlap it by 4' or so which will allow the canvas to flap open some in the wind without exposing the inside of the sukkah except in high wind.

I only needed 3 pieces of canvas as was able to cover 3 sides and most of the other side. The sukkah is positioned such that the part without canvas is right around the door into the apartment, so it feels like the sukkah has 4 walls.

Once the canvas it up, go around and lash the corners with the wire tie. You can punch it through the canvas and wrap around the bit of canvas that is wrapped around the pipe. You may want to get the wire tight by using pliers to twist the wire together (like a wire tie for a trash bag). Just keep in mind that the wire isn't very heavy and you can twist it to snapping. You want it to have just a little give. My theory is bamboo bends and doesn't break so I like the sukkah to have just a little movement in all joints.

Use the wire tie to secure the bottom of the canvas to the railing. This way it won't blow around in the wind. Where you are able tie the nylon string to the top pipe and to the rail. This way if the sukkah gets wind under it and starts to lift, hopefully the nylon string keeps it from sailing off your balcony.

The final step is to put a covering on and secure it. We order special Kosher suchach. There are a few options out there but what we got was cut bamboo held tightly together with interwoven nylon string. I put it on top of the sukkah, unrolled it, put two cross members across the width of the sukkah (technically you should do the length, but I didn't have long enough cross member) and secured it with wire tie. It was certainly the easiest part since we bought that preassembled.

I prefer a less tightly woven roof because you can see the stars and it's easier to hang decor from, but I must say the suchach we had made it easy and looked great.

the completed sukkah (from inside)
notice how the top of the canvas is wrapped around the pipe

Chag sameach!