Tag Archives: qcon

managing millions of data services at heroku – live blogging at qcon

Posted on by
Reply

Managing Millions of Data Services @ Heroku
Speaker: Gabe Enslein

See the list of all blog posts from the conference

AWS S3 failure

  • February 28, 2017 – AWS S3 outage – pager duty failed to give message
  • Down for about 6 hours
  • Heroku recovered before everyone went to bed (10pm Eastern)
  • Avoid failure by having failover strategies
  • Would have taken 35 years to recover if had to do all tasks manually
  • No Heroku customers lost any data

Concepts

  • Layers of abstraction simplify evelopment
  • Everything rus on hardware at some level down
  • Abstractions can hide real problem
  • Can be harder to reproduce problems
  • Can model many tasks as state machines – both deterministic and non-deterministic moels

“just” implies it is easy. Be skeptical. How easy to repeat? How often is “just”

Automate yourself out of a job – recurring and one off work

If haven’t gotten a heartbeat in a while, don’t know health.

States
Not all states used by all systems

  • installing
  • available
  • uncertain
  • unavailable
  • retiring
  • retired
  • archived
  • terminated
  • restart
  • upgrading

Check on

  • Backups
  • Replication
  • Security
  • Performance

Manual fixes can cause more problems than started with. Immutuable infrastrucure enforces the “just”. Script the exceptions; don’t manually tinker. “Break Glass” in case of emergency procedures still help. Modeling emergency remedies help so computer can fix when detects instead of waking someone up.

Infrastructure is code, not a second class citizen. Test it for functionality, performance and regression.

Then March 15, 2017, there was a Linux denial of service and admin escalation vulnerability. Needed to see none of the images were affected. Can fix image so customers get when start up.

Key Takeaways

  • Automate yourself out of regular operations
  • Have emergency automation in place – scripts, jobs, etc
  • Make routine failover strategies
  • Treat infrastructure as full units
  • Abstractions have their limits

 

on getting old(er) in tech – live blogging from qcon

Posted on by
Reply

On Getting Old(er) in Tech – Staying Relevant
Speaker: Don Denoncourt

See the list of all blog posts from the conference

Speaker is 57. In audience, nobody admitted to being older than that. About a dozen in their 50s. (I’m nowhere near 60. I came because I do want to stay in tech for my career so these problems will affect me someday)

Stats

  • Average of IT workers Facebook: 28
  • Average of IT workers LinkedIn: 29
  • Average of IT workers Google: 30
  • Average of all American workers: 42

Strategies to Stay Relevant

  • If best, have no opportunity to learn. Ok to work to be medium so learn from teammates.
  • If the best, find people elsewhere to collaborate/practice/learn
  • “Cubical dancing” – learn from everyone you work with. Ask different people for help. Learn from people who want to share.
  • Cross boundaries – Every time you fail, your brain gets stronger. You might not learn, but still stronger.
  • Challenge yourself – try something new; learn on own. Don’t want to be bored. Look at what is new on the horizon that need to jump into.

What to do if you are the best in your shop

  • Read code – compare to code of others
  • Join open source
  • Write blog posts – learn from writing
  • Speak at user groups and conferences
  • Discover technologies that other team members know more about
  • Mentor – learn from mentee’s ideas

Learning regularly

  • “10 years experience or 1 year 10 times” – can continue to learn in same job. But not everyone does.
  • “After doing 1 year 10 times, folks often lose the ability to learn”
  • Brain starts to lose ability after 30. Need to exercise it
  • Can be too late if stop learning
  • “Once you stop learning, you start dying” -Einstein
  • I plan on being in IT more than 10 years, need to beocme a lifelon learner

    • Perspective (for technologies): You are only as good as your last two years of accomplishment. After two years of pair programming, developers are roughly equal. Need to acquire new knowledge regularly.
    [this is a good resume point for people like me who have worked at one company a long time; highlight what recent]

    Learning types

    • Know your learnng style – books, videos, coursera
    • Remember that will learn most at beginning/end of learning session. Short bursts of learning help. Find short things to learn like Ruby Tapas
    • Go over material in muliple passes. Ex: multiple books on same subject
    • Mental pump – do something each day. Learn a lot when you graduate college and start working. Continue that.
    • Surge – blast of energy like pre-conference, pre-project launch, between projects, when job hunting. Take advantage of time and energy
    • Stockpile resources – keep track of books/bog/courses/videos people like. Keep conference/seminar videos. Keep newsletters. Then look at when ready/have time.

    Finding time

    • Use your commute time
    • Use your exercise time
    • Listen to podcasts or audio books

    On Getting Hired

    • Be up front about your age. Don’t color hair or hide experience made joke in application about knowing old tech and get guess age
    • Look and stay fit
    • Be interesting have hobbies
    • Take a cut in salary for new opportunities
    • Post code on github

    the effective remote developer – live blogging at qcon

    Posted on by
    Reply

    The Effective Remote Developer
    Speaker: David Copeland @davetron5000

    See the list of all blog posts from the conference

    David has worked for 4 years remotely. Most people are remote.

    Definition of remote

    • “You are remote if you do not often interface face-to-face with the people you work with”
    • hard – lone wolf – only one person is remote
    • easy – everyone is remote
    • also – multiple offices

    Definition of effective

    • Productiving value
    • Agency – don’t just want to be closing jira tickets
    • Inclusion – don’t want to be that guy in Alabama that people send work to
    • Rewarding

    Not easy; takes constant upkeep

    Benefits

    • Freedom & flexibility – no commute, acccess to own kitchen, live where want
    • Company has access to wider pool of talent – slowing down ability to liver by restricting to specific area

    Must build with people you don’t know and maintain trust with people that don’t.

    Trust

    • “the half life of trust is six weeks – it must constantly be replenished”
    • Communicate frequently and clearly – Turn big projects into small ones. Everyone knows what working on. Get early feedback. So shows value delivering. Provide more context. Read what wrote and revise at least once. Use bold/underline/whitespace for clarity.
    • Be responsive, but set boundaries – publish your working hours (including time zones). Put in email signature and comment if meeting outside working hours. Developer a worklow where you aren’t heads down coding for hours; develop mental SLAs for communication. Specific affirming (positive) feedback is useful.
    • Assume good intentions – we are not good at critiquing. remember the reviewer is trying to help even if sounds cold and harsh.
    • Help others help you – go to chat or video for people who don’t communicate well over emai. Find out how everyone best communicates. Be specific in what type of feedback you want

    Base level of technology

    • Easiest thing, but need to be successful
    • Chat system that is easy to use
    • Video conference that supports multiple people
    • Better mic than laptop mic

    Types of communication

    • Coding – Think about smallest viable change. Write better change requests so can judge your changes. Learn to screencast (quick video) and diagram.
    • Synchronous – ex: video chat. Experience people as a human when not present. Be prepared. Formulate opinion in your mind. Use nouns instead of pronouns more than you think in case a few words drop. Also, pause more frequently and ask for feeback. “Any questions before I move on”. Don’t multitask; pay attention – best case is missing info; worst case is getting called out or having to ask. Have regular backchanel for tech issues.
    • Asynchronous
    • Socializing – If quiet in office, people still know who you are and that humanizes you. If remote, you are a producer of emails. Use time before meeting starts to socialize. Have one on ones with no agenda. Like scheduling time to stand around the water cooler. Travel to meet others in person. Accept that will miss happy hours

    Remember computers are terrible and nothing works. Can bond over shared bad experience.

    When interview, do chat and give take home project (add a few features) then pair program remotely to add another feature. Then fly onsite to interview. Have hired a few without flying in

    Dedicated area at home to work.

    Many of these tips are helpful even without remote developers.