Ubuntu Auto-Mute
Av någon anledning drabbas jag ofta av irriterande bugg hos ljudhanteraren i Ubuntu – detta har följt mig över flera ominstallationer och maskiner. Däremot inte i Fedora på samma hårdvara…
Plötsligt får Ubuntu för sig att min någon förgrundsprocess är det viktigaste som finns, och min podcast i bakgrunden både pausas, och sätts i tyst läge. Detta kan triggas av så godtyckliga saker som att växla tillbaka från VLC till vilket program jag nu använder för tillfället.
Personligen anser jag att jag klarar av att hantera mina ljudinställningar på egen hand!
De flesta sökningar på detta problem leder till en inställning av alsamixer, vilket inte alltid löser problemet.
sudo alsamixer # F5, hitta Auto Mute, sätt till disabled, ESC
sudo alsactl store
Om det inte är tillräckligt så är ljudhanterare nummer två också aktiverad: pulseaudio.
Pulseaudio har en modul som försöker identifiera viktiga ljudprocesser (skype-samtal och så vidare). Redigera filen enligt nedan.
sudo vim /etc/pulse/default.pa
# load-module module-role-cork # kommentera denna
Starta sedan om pulseaudio
if [[ $(pulseaudio --check) -eq 0 ]]; then
pulseaudio -k;
pulseaudio -D;
ps -ef | grep pulseaudio
fi
Förhoppningsvis är detta tillräckligt för att lösa dina ljudproblem.
JAX 2018 Enterprise integration patterns: A look back and their use in today’s serverless computing
Kod- och demotung föreläsning.
What is Serverless?
- Abstraction of servers
- event-driven/instant scale
- micro-billing
Run my code, at an running tab cost, event driven.
Monolith ==> N microservices ==> N*M Functions (==> A LOT of moving parts…)
From On-prem servers to serverless
Hardware =:= servers = a lot of management on every level
Virtualization =:= OS = just give me SSH and I’m good to go!
Kubernetes =:= container = just run my container
Serverless platform =:= Function = just take my code
Options
Cook your own
- Apache OpenWhisk
- OpenFaaS
- Fn Project
- Project Riff
- Kubeless
Cloud platforms
- AWS Lambda
- Azuse function
- Google Cloud Functions
- IBM Cloud Functions
- Pivotal Function Service (coming soon)
Azure Functions
Demonstration.
Open Source (med ett kommersiellt hostingalternativ)
.NET runtime.
Stöder ett antal språk.
Spring Cloud Function tillåter att man skriver adaptrar för att separera verksamhetslogik från annat, och mappa mot deployade funktioner.
Enterprise Integration Patterns
NM Functions need to communicate in an ordered manner somehow.
Boktips: Enterprise Integration Patterns
Apache Camel.
Demo vanligt förekommande mönster i Camel.
Repetition syntax.
Solutions for Application Integrations
Cloud Integrations Services
Azure Logic Apps, Oracle Integration Cloud, etc
Integration frameworks
Camel, etc
ESB patterns
Camel and Serverless Functions
Integrationsskikt med Camel som klistrer mellan serverlösa funktioner.
Demo!
JAX 2018 A craftman’s guide to designing a clean architecture
By Marcus Biel, Clean Code Academy
Defining a clean architecture
Should be simple top-down.
Sadly, often real world complexity knocks on the door, and the sketch isn’t very clean after all.
Hide the truth? NO!
Build systems with modules
Hexagonal architecural pattern
Split architecture in infrastructure and domain.
Infrastructure layer is responsible for communication etc.
Head First Domain-Driven Design
Enforce layering with Java Modules.
Building blocks of a clean architecture
- Size
- Naming
- Encapsulation
- Coupling and cohesion
Size matters
Smaller is better – shy away from complexity.
Guideline upper limit for each of
- modules
- packages
- classes
- methods
Know when you violate this and reflect on it.
Naming
- clean names drive high cohesion (Customer, AccountNumber)
- use service pattern judiciously
- clean names are team work
- rename on new insights
A good name groks the purpose.
Understand the goal of your business!
Encapsulation
- technically enforces of how the system should be used
- getters and settes violate encapsulation
- use package private more often!
Coupling and cohesion
Coupling: Avoid N:N, prefer clean dependency chains.
Prefer lower coupling farther out in the layers of your architecture.
Cohesion: ”single responsibility principle”. Låt lika leka med lika == high cohesion.
High cohesion requires in-depth knowledge of the domain.
JAX 2018 Leadership at every level
By Liz Keogh https://lizkeogh.com/
Stephen Bungay the art of action
Utan att veta vad planen är, så början folk gissa.
Managers blir stressade och detaljerar mera, vilket sällan hjälper till att uppfylla målet med förändringen.
Instinktiv motvilja mot osäkerhet.
Flickr och Slack avknoppningar från samma misslyckade MMO till följd av finanskriser.
Estimating complexity
5 nobody’s done it before
4 someone outisde of the org has done it
3 someone in org has done it
2 someone on team has done it
1 we all know how to do it
Samtidigt ger den högsta komplexiteten de största vinsterna.
Därför är det ofta fel att välja de lättaste sakerna först eftersom de sällan ger mervärde på lång sikt.
Information Arrival. <== ramarna sätts för tidigt
Deliberate Discovery
Assume ignorance
Assume second order ignorance
Optimize for discovery
Real Options
Options have intrinsic value
Options expire
Never commit early unless you know why
Boktips Commitment <== Olav Maasen et al
Palchinsky Principles
Seek out new ideas and try new things
Do it on a scale where you can afford to fail
Learn from your mistakes
Googles Project Aristotle om trygghet i teamen [1] [2]
TDD!
Three models of feedback
- Porpoise feedback
- Anchor the things you value
- Beröm bra beteende etc
- Sandwich model
- Anchor what you value
- (Provide feedback to increase effectiveness) <== people write their own code, often reduntant
- End with a bright future
- Atkins
- Sandwich without bread (just feedback)
Sensemaker <== topologisk karta över åsiktsklimat
Var ligger organisationens dispositioner centrerade?
- Anchor and amplify!
Relentless positivity
Odla effektivitet genom att fokusera på det positiva, och förstärk det.
JAX 2018 Don’t Make it a Race: The Four Common Concurrency Control Patterns
By Jack Shirazi, Hotels.com
3 levels of concurrency
- High level
- Seven concurrency models in seven weeks
- Models (how you will wirte your prorgam)
- Threds & locks
- Etc
- Medium concurrency patterns
- …
- Low blocks
- @runnable
- Thread
- etc
Vilka strategiska val är viktiga innan du börjar jobba?
Shared Mutable State
- Användas av flera trådar
- Kan ändras
- Stateful
State
Kan försöka utlokalisera ditt state
Mutable
Svårt att bygga.
…Men eventually-immutable går ibland att uppnå.
Final private fields.
Nackdelar ganska mycket kopierande.
Shared
Thread local state
Ta bort ett av orden, så har du inte längre ett problem med concurrency.
Shared immutble state:
- functional programming,
- mapreduce
Unshared mutable state
- actors,
- single threaded event,
- etc.
Pessimistic locking
Javas synchonized
Lätt att implementera – yay
Enkeltrådat.
Optmistic transaction
Map ==> concurrentMap
Måste trolla lite med uppdatering av objekt.
Queue to a single thread
Gör en enkeltrådad runnable.
Hantera som en vanlig add() på klientsidan.
Partitioning the data
Dela upp datat så att respektive kan agera enkeltrådat.
Putting it all together
Går bra att blanda de olika mönstren för att lösa ditt problem.
I praktiken
- Försöka identifiera dina möjliga problemområden (concurrency) så tidigt som möjligt, helst redan på den arkitekturella nivån.
- Försök eliminera Shared|Mutable|State
- Går det att använda en högnivåmodell för concurrency?
- Förstå ditt behov av concurrency,
- kavla upp ärmarna, och gör det själv.
- Kapsla in ditt problem så gott du kan.
- Använd persistent [1]?
- Använda existerande datastrukturer när det går.
JAX 2018 Software Engineers are bad at speaking in public
By Erika Tanti, Ixaris Solutions @ericathedev
A 1967 study set the prejudice that software engineers lack communication skills.
The new agile agenda has been prioritizing communication since early 2000:s (SCRUM etc identifies person-to-person contact as a key factor to success).
The speaker, him- or herself, often devalues their own impact. Often gives a significantly more professional and comfident air than oneself estimates.
Practise makes perfect!
Meetings
1:N communication is not a meeting, it is an announcement!
Active participation is key to success.
Confirmation bias – when a couple of people agrees, it gets instinctively more difficult to make objections.
Come prepared, read the agenda, think beforehand.
Networking
Take an advantage of random encounters!
Listen to their stories, learn, reciprocate.
YOLO! Just do it, try try try.
Erica has the gall to propose we put down our phones and make us available for a conversation 🙂
Presentations
Don’t just present facts, convey feelings as well.
Emotional impact lubricates the message, fascilitating success.
Slides are difficult to get right, and to manage.
Should convey images, rather than present a verbatim copy of your speech.
How to make that work in an enterprise environment (break the shackles of PowerPoint communication)?
Establish eye contact! You are the stage, not the presentation.
Feedback is the key to improvement!
Find your safe space
Books on public speaking
JAX 2018 DevOps with Kubernetes and Helm
By Jessica Deen, Microsoft
https://jaxlondon.com/devops-continuous-delivery/devops-with-kubernetes-and-helm/
Codefresh kubernetes-native jenkins
Draft hjälper till med generering av de yaml-filer som behövs, och stöder lokal deploy.
Fantastisk föreläsning, men mycket hands-on demo.
Se länk nedan.
JAX 2018 Effective leadership in Agile/DevOps environments
By Michiel Rook, https://www.linkedin.com/company/touchdown-consulting-services
Hur utöva ledarskap i självorganiserande team?
Ledarskap handlar om att transformera människor så att de kan arbeta tillsammans mot ett gemensamt mål.
Individuella medlemmar i ett team har olika mognad, vilket påverkan teamet som helhet. Teamet har också en mognad, och en trygghet inom gruppen.
Genomgång fler olika ledartyper.
- Directive
- Participatory
- Coaching
- Servant
- Situational leadership model.
”Effective leaders stir an intangible but very real desire inside people” – General Stanley McChrystal
Develop people
Turn the ship around by Marquet
Develop leaders
Provide space to grow
Important traits
”A leader leads by eample, not by force” – Sun Tzu
Integrity is demonstrated through actions
Empathy
- Be visible
- Be present
- Be Approachable
- Be responsible
- Be adaptable
- Be vulnurable
Get out of the way!
Leaders add value.
Experiment – find your own leadership style – learn from your mistakes.
JAX 2018 The Bumpy road towards containerized Microservices
Nicky Wrightson, FinancialTimes
200 containerized services + kubernetes orchestration across two regions.
Why containers
Monoliths didn’t cut it if they were to keep relieince while developing new features
80% cost reduction using containers.
Increased testability using containers (everything is guaranteed to be in place).
Serverless
Too much change too soon!
Some serverless components today.
PoC early 2015
Kubernetes not around, so built their own.
Java not extremely resource conservative compared to e.g. Go. ==> High Container footprint
Use only where needed, consider lighter alternatives elsewhere.
Containerise all the things == a lot of hard work
Of course, changed DB to Neo4J at the same time as they did everything else…
Control issues (mapp service hw req vs hosted VM)
Stateful services make containers sad
Limit container growth.
Monitor at the right level to get the high level view. <== put effort in Core Business Value critical services.
SIMPLE deployment pipeline.
Operational Testing awareness.
Automate the complex things, even if they are rarely done
AWS dropped Fleet support ==> forced migration to Kubernetes and Helm – yay!
Tweak deployment details during active development during migration.
Benefits
Cost
Control
Operationally supportable
Deployments are more graceful
More self-healing
Next?
Rewrite parts of the architecture to fit into all of the nice new features.
Monolithic cluster via namespaces?
Continuous migration?
”3 innovation tokens” <== gör vad du är bra på
- Köp resten
JAX 2018 An Architect’s Guide to Site Reliability Engineering
Monolithics principles don’t necessarily apply to microservices.
How we work together matters.
Communication is even more important in a complec world.
So what is the history of IT?
Apollo program Margaret Hamilton first SRE.
Wanted to implement error checking to avoid data erasure during takeoff. Management denied this, shit followed 1968.
Hope Is Not A Strategy!
Monolith + sysop ==> microservices + devops
CORBA ==> EJB ==> SOA ==> API first
:. Cambrian explosion of API:s
E.g. Dark Sky API <== väderapp
Amazon: Steve Yegge the Bezos mandate: all data available between public service API:s.
Present day
Troubleshooting multilevel microservice arhitecture difficult. Who is responsible?
Microservice definition: rewriteable in under 2 weeks.
Everything changing makes sysop sad – how to make them happier?
- Replace maual tasks with automation!
- Focus on engineering
- Helpful to know Unix and network stack
- CAB won’t cut it
How to move fast safely?
Ops must be able to support a dynamic environment
Important to prioritize, setting aside time for this – else no automation will get done.
Establish sane SLO:s
Manage risk, shit will break.
Risk is a continuum!
How much does catastrophic failure cost? ==> Lost revenue vs cost of redundancy.
Firefightning isn’t a long term solution. It may be better to accept short term lowered SLO:s to engineer a better long term solution.
Archilochus: ”We don’t rise to the level of our expectations, we fall to the level of our training” [1]
MEANINGFUL moitoring
Alerts should require a human. The rest should self-heal.
Less grunt!
Vital to learn from outages ==> Post Mortem without blame. Consider making a PM template.
Identify
Online examples available.
Wheel of Misfortune <== failure role playing
Some services are more equal than others.
If uptime goal of 99%, error budget is 1% ==> use it to experiment
Draw up the architecure! Make sure everyone understands/shares a common model of the architecture.
Boktips: The Checklist Manifesto
Quantifiable and Measurable
Go through your checklists, does every service fulfill the demands?
Boktips: Building evolutionary architectures
Architectural reviews ==>
- identify failure points.
- Failure scenarios
- Chaos engineering
We all need to evolve to succeed!
Boktips: Site Reliability Engineering.
