Accidentally in Code

Tag: iosdevuk

  • #iOSDevUK: UIKit Dynamics

    #iOSDevUK: UIKit Dynamics

    My notes from Simon‘s excellent talk at iOSDevUK [his slides].

    simulation of the world exploding

    Physics for UIKit.

    “Visual layers and realistic motion impart vitality and heighten users’ delight and understanding”

    Buttons used to look like buttons, now they don’t. Don’t have visual cues. Compensate using Dynamics to add some motion.

    Not for flappy birds. Has tried it, can get most of the way there. But there are fundamental missing parts. This is the road to disaster. Not what it is designed for, there are better frameworks out there.

    How it works:

    • Physics without having to understand all the hard stuff.
    • UIDynamicItem (e.g. a view): a thing you can animate around the screen.
    • UIDynamicBehavior (e.g. gravity): things that can happen to those things.
    • UIDynamicAnimator: ties those together, responsible for running those animations.

    UIDynamicItem

    • Just a protocol.
    • Implemented by UIView.
    • Defines 3 animatable properties:
      • bounds
      • center
      • transform

    UIDynamicAnimator

    • Responsible for applying behaviours to items.
    • Defines a reference view, whose coordinate system is used for animations.
    • Manages animations.
    • Pauses when animations end.
    • Use in a ViewController. Should be a property in a VC. Use VC’s own view as the reference view.

    UIDynamicBehavior

    • Models a real world physical behaviour.

    Built in behaviours:

    • Attachement behaviour:
      • Connects two views together.
      • Move one view and another moves with it.
      • Can use an anchor point rather than a second view.
      • Can be springy (see damping, frequency properties).
    • Collision
    • Gravity
      • Models gravity.
      • Add to an item and it falls downwards.
      • You can optionally configure magnitude and angle.
    • Push
      • Models a force being applied to an item.
      • Instantaneous (a kick) or continuous (a rocket engine).
    • Snap
      • Snap a view back into place.
      • Imagine held in place by four springs.
      • Set damping to control how bouncy it is.
    • DynamicItem
      • Just another dynamic behaviour.
      • Used to tell the animator about the state of dynamic items.
      • Like a meta behaviour.
      • Add additional properties:
        • Density
        • Elasticity
        • Linear velocity
        • Etc…

    Gotcha

    Animators pause when nothing left to animate. what happens when it goes outside bounds?

    Actually view continues accelerating as it falls down towards the centre of the earth.

    This is bad because UIViews are flammable. If carried on unchecked, the earth explodes. Which is bad because kittens will die.

    Stopping the animation:

    • All dynamic behaviours have an action block.
    • Gets executed for every frame
    • Determine if out of view, if so remove from frame.

    Basics. This is it, no hidden complicated stuff.

    Tweetbot uses excessively extensively.

    Summary:

    • New in iOS 7
    • Give real physical properties with little code
      • Create animator
      • Create behaviour
      • Associate

    Do:

    • Delight and inform

    Don’t:

    • Try and use with auto layout.
    • Try and recreate angry birds.
  • #iOSDevUK: Marcus Zarra – Not Invented Here

    #iOSDevUK: Marcus Zarra – Not Invented Here

    Saw woman texting with a T9 phone. Stopped, looked, made sure he saw what he really saw.

    Presenting from a phone. First presentation, used a projector. Amazing how far we have come.

    Generally known as an opinionated person. Don’t speak in wishy washy words, very boolean. Either believe or don’t believe. If not, just shut up.

    In career get feedback, “brash”, etc.

    One thing is claiming he has a dysfunction called “not invented here”. Yelled at for wanting to write things himself, not wanting to use other people’s solutions.

    Think it’s a problem, being egotistical. Thinking he’s better than everyone else.

    In own introspection. Am I really this evil person? Do I need to fix this? Realised no, really don’t. Positive side.

    Why he doesn’t like other people’s code. Why he doesn’t like 3rd party frameworks.

    Lot of reasons. One that it is not, code quality.

    Code quality is a complex subject, not going to put it on one side. Talk on it’s own, if could even fit in a talk.

    “All code sucks, eventually. All code suffers from bit rot, no matter what.”

    Three points:

    • Reinventing the wheel.
    • Becoming a better developer.
    • Code ownership and maintenance.

    Reinventing the Wheel

    As an engineer, write a lot of networking code, persistence code.

    Whenever start a new project, start from zero. Don’t have a cheat sheet, or a code snippet, or a template.

    Write it each time not because like torturing himself, because he knows can write it better. Smarter today than yesterday, especially than three months ago.

    Shouldn’t be reinventing the wheel, but iterating the wheel is something that we should be doing. That is what we are really doing when we do that code over again.

    Becoming a Better Developer

    “Any insufficiently understood technology is indistinguishable from magic.”

    Think something is hard, never bother to go out and look. By writing it yourself, disperse the magic. In it’s place you have code you understand.

    “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”

    Code Ownership and Maintenance

    Even though write it today, no guarantee can read it tomorrow. A year from now it’s going to be complete garbage. When write it today, want to be able to read it in a month.

    • Risk management with Apple (they change things all the time).
    • 3rd party framework is like introducing to an unmonitored team member.
    • No guarantee of updates.
    • No guarantee of quality or direction.
    • Risk of App Store rejections.

    Happy Medium

    • There is good code out there.
    • Manage your risk: reward needs to justify the risk.
    • Consume the code, own the code, make it yours.
    • Learn the underlying technology before adopting a framework.
    • Stop inheriting other people’s problems.

    “You have a problem so you decide to make a framework. Now everybody has a problem”. @secboffin

     

  • #iOSDevUK: Hacking Health

    #iOSDevUK: Hacking Health

    most common chronic conditions
    Credit: Centers for Disease Control and Prevention

    My notes from the talk Emily gave at iOSDevUK.

    What are health apps?

    • Step counters
    • Fitness trackers
    • Diabetes apps
    • Heart rate monitors
    • Bluetooth enabled medical devices

    Apple and Google have decided this is where the future is. Gone in. Apple, Healthkit. Google, GFit. Standardized APIs getting information with defined types, centralised storage. Enables gathering data from a range of different sources, don’t need to connect with a billion different APIs. Fine grained permissioning – user is in control.

    If user says no, can no longer see that information is even there. E.g. if you know blood sugar is being stored, even if can’t see it, can infer things.

    Parkinsons App:

    • Insight into effects of personal choices.
    • Better understanding of redactions to medications.
    • Ease of sharing information with care circle.
    • More accurate information provided to medical practitioners.

    Parkinsons – sleep and eat has tremendous effect. Give people information on this, also give them control over the life. Insight into reactions to medications.

    Parkinsons patients see consultants for 10 minutes every 6-8 months. Have to provide ALL information, and practitioner has to provide information. Done using a questionnaire. Incredibly difficult thing for users/patients to be able to remember. Influenced by their mood when they fill it in. Helping people see on average every day, able to use that 10 minute slot far better.

    App:

    • Enter and alert on medication schedule.
    • Track adherence.
    • Track lifestyle factors, mood, diet, fitness etc.
    • Measuring severity of symptoms (e.g. use gyroscope to measure tremor, compare before and after).
    • Track side effects.
    • Allow correlation between lifestyle choices and presentation of condition.

    Issues:

    • Ethical
    • Legal
    • Technical

    Do no harm. Hippocratic oath. We are devs not doctors, probably not going to do harm, but have a duty to our users that our app don’t cause them to do something that will cause them harm.

    Patients vulnerable. Can make decisions based on what you show. E.g. diabetics and blood sugar.

    E.g.:

    • Self diagnosis app:
      • Misdiagnosis.
      • Delay in seeking proper medical advice.
      • Self medication problems:
        • Unknown interactions.
        • Unwanted side effects.

    Pay attention to potential harm. Think very carefully about design.

    Respect:

    • Your users are more than their condition.
    • Think about people rather than patients.
    • Use language carefully.
    • Think about how you word and time notifications (e.g. if giving a presentation from mobile, what if interrupted? Allow to turn off).

    Consent:

    • People want to protect their personal medical information.
    • Informed consent around data sharing and collection.
    • Opt in, not opt out (granular control).
    • HealthKit and GFit permissioning.
    • If not prepared to tell people what you’re exactly doing with their data, think about what you are doing.

    Stats are hard:

    • Be careful if use stats to tell people how safe it is.
    • People are often scared by statistics.

    Transparency and Honesty:

    • Users will not share data with you unless they trust you with it.
    • Expose your ethics, standards and decision making process.
    • Warrant Canary – libraries in the US used to put a sign in the window, saying “FBI has not been here to raid information”. If removed, it’s a sign to indicate, even when they couldn’t tell people that they had been raided by the FBI.
      • rsync.net – first company to use things.

    “When you start to gather and store information about a person that they would normally only share with their closest family and medical carers, you have a responsibility to that person to care about what happens to that data. If you do not care, in my opinion, you have no business working with private, personal medical information.” ~Emily

    Legal Stuff

    The diagnosis Line (what is and isn’t diagnosis).

    • Example: 23 and Me
      • Sent back statistical likelihood about genes you are carrying.
      • People don’t understand stats, were interpreting as a diagnosis.
      • Rebranded as genetic detection service (gave people analysis, no conclusions).
    • If taking data, analysing it, presenting conclusions, can be interpreted as diagnosis. This may need to be regulated.
    • US and Europe have different rules.
    • Best to present information, allow users to draw conclusions themselves.

    Data protection app:

    • Only collect what you need.
    • Keep it secure.
    • Ensure relevant and up to date.
    • Only hold as much as you need for as long as you need.
    • Allow the subject of the information to see it on request.
    • Fair processing: ensure it is handled in ways that are transparent and that they would reasonably expect.
    • Do not transfer outside of the EEA unless compliance is ensured.

    HL7 and HIPPA

    • Standard for sharing health data and US version.
    • International standards for interoperability of health information technology.
    • HealthKit does not conform to HL7 but does to HIPAA.

    Don’t overlook data. Don’t lose anything.

    Technological

    Secure storage:

    • Disk encryption.
    • Public key infrastructure.
    • IP security.
    • Data masking.
    • Data erasure.

    Apple doesn’t seem to have published how they are storing.

    Not just about how you’re storing but also about your process. If only need to bribe one person, then your data is not secure.

    Pseudonymisation:

    • Huge topic.
    • Ensuring individuals are statistically hard to identify from data.
    • Separating out PII from other information:
      • Different servers, databases.
    • Why should they not be identifiable:
      • E.g. Cancer patients data leak. Sold onto a research company, contained contact data and occupations. Patients were contacted directly, and asked intrusive questions.
    • Who is accessing your data and what do they need?
      • E.g. Insurance company. If could recognise people, might give them higher premiums because of things like not taking medication on time.

    A11y:

    • Good practise.
    • Think about who your audience is.
      • e.g. Parkinsons, tremors.
    • Coordination symptoms.
    • Medication side effects.

    Miscalibration:

    • E.g. Therac-25
      • Radiation machine. One high powered beam used with something else, other low.
      • 6 accidents resulted in 6 patients being given 100x intended dose.
      • Caused by a race condition caused by a byte counter overflow in the calibration.
      • Poor calibration could cause a lot of harm – giving people bad information about their medical state.
    • Check and double check calibration.
    • Publish your algorithms.

    Localisation – conversions:

    • HealthKit and GFit provide APIs for this.
    • Even NSA get this wrong:
      • E.g. Mars client auditor.
    • Language.
      •  American Airlines. “Fly in leather” campaign, became “Fly Naked”
      • Dairy association. “Got milk?” became “Are you lactating?”
      • Pepsi. “Pepsi will bring your ancestors back from the dead”

    Data provenance:

    • Where does data come from, and can it be trusted?
      • Important both for data you use and data you provide.
      • Especially if selling on to research organisations.
    • How accurate is it?
    • How could inaccuracy hurt my users?
    • Impact of HealthKit and GFit. You do not know where that data is coming from.

    Why Bother?

    Common causes of death. If could make apps to make these people to live more fulfilling lives, or prevent them from getting that condition in the first place.

    Most common chronic conditions: high blood pressure. Altzimers. Could improve lives,

    • Improve lives, maybe even save a few.
    • Empower people.
    • Improve quality of care.
    • Provide data to help solve.