Glad to help!

I can help push you in the right direction, at least.

When you see that loading a content URL directly fails, it means there is some sort of access mechanism that goes beyond the URL itself. My guess is that it’s in the headers. It may be something like JWT, but even if it’s dynamically calculated, it’s probably valid for a little while.

Download Charles, HTTPScoop, or similar. Filter the sniffing down to the URL you know is the video. Then, compare the stuff you see in their request that works with what you see in your own that doesn’t. That’s at least gonna get ya started.

You also might consider getting Xcode and learning Swift with Playgrounds. They build-and-run as you type, which is very flexible and easy to use. There are WWDC videos out that show you how to develop and inspect an algorithm using playgrounds, before you place it in your production code.

Playgrounds also allow apple's sample code in their e-books to be live and editable, which makes them a fun read.

Swift is a modern language that offers some FP styled concepts and a modern object oriented system, and the toolchains are available for at least linux and mac, but I think for windows too. So, Swift is a good language to pick up to get to grips with modern architectures.

You might consider getting a Cozmo. It's a small robot that has an active development community and a really vibrant and approachable SDK.

The scripting language it uses is Python, which is a popular starting language and is also used for lots of real things.

I know it involves buying a product, but on the flip side, you get to see your software operating a real live robot even with a few-line example. The SDK offers very high level functions, but mid- and low-level ones too. If you wanted to dive "deep enough", you could even pipe the raw data from all Cozmo's sensors into an app on the desktop and get really crazy with it.

Well, I guess maybe I'm the only one, but I enjoy FP as an adjunct to Object-Oriented. It is incredibly useful in our applications, even though lots of our FP-purity isn't enforced by the language.

Functional Programming is about transforming values in a stream-like manner. It gives you strong correctness guarantees from your compiler, and in any case where you want to turn data A into data B in a pipelining process, going as FP as you can manage doesn't seem to lead you wrong. I think the thing about state is that there are just too many cases where the overhead of "building" or "extracting" the state is huge. When you're dealing with a user interface, for example, there IS state--it's what the user is seeing on their screen.

But for anything involving pipelining, it's good stuff.

Ok, let me point one thing out: that was a single guy.

Scrum is for managing teams, not managing single engineers. I absolutely believe one guy on his own could produce wicked fast, handle his own shit, et cetera.

But if you took four of him and just sent them off in a separate room like that, it would be a completely different story. Anybody worth their development salt can work fast and hard and make something awesome, I believe that.

But if you are talking about using scrum to manage a single person, you're trying to use a power drill to put a nail in the wall. It's apples to oranges.

It's a logical fallacy for me to simply insist that your scrum isn't real scrum. It's the "no true scottsman" fallacy. I absolutely believe in shittily-run scrum, and like I said, it really, really sounds to me like your managers leafed through the scrum manual and took notes on "this is how I need to phrase it when I jump on my engineers' asses so that they can't argue with me".

What do you write in? My company needs engineers a lot and we don't suck.

I'll address these points in order, but I really need to call out this one first, because it says everything that you really need to hear.

He is going to use AGILE how it is mean to be, without the slowdown.

Well said! "Agile how it is meant to be". In other words, the process you are doing is "agile how it is not meant to be". Your "slowdown" is external. Somebody is not enforcing the rules of scrum to prevent the slowdown.

Now, to address all your other points one by one...

No. Give him the same user stories as your highly successful SCRUM team. That is his general direction he is going to head for. Don't expect him to follow the user stories, it is the end result that counts.

This doesn't exactly make sense. Stories are small packets of acceptance criteria. They must be "followed" or else the end result won't match them, so that doesn't make sense. If you're referring to the strict ordering of stories by priority, which I think you might be, then you're certainly on a moderately dysfunctional team. The ordering of stories is dependent on which feature must build on the code of another. I don't care how cool your engineer is, if I have a screen C that is a detail view of an item selected from a list on screen A, then screen A has to be written first. Code quality will suffer otherwise.

No pre-planning no scheduling, no fixed deadline. Just a deadline around your next demo but give him wiggle room to delay a few days, no code review, no stand-up meeting. He builds from withing the code towards the desired result.

If you are fixing a deadline and yelling at your engineers when they are 3 days from the end of the sprint, then you are not doing Scrum. Setting the contents of a sprint does not grant the product manager the authority to yell at you to work extra hours, to insist that your team fucked up, or to tie a product demo deadline to the day the sprint ends. Sprint endings are designed to create a feedback loop that continually refines your team's ability to commit only to the amount of work you can actually do.

In particular, if you allow a team to say, "Ok, we have two weeks worth of work." and then, they work for two and a half or three weeks before it's done, what's to stop them from committing to "Ok, we have two weeks worth of work" again the next sprint, and missing again? Scrum doesn't allow you to yell at your engineers for missing their sprint targets. Rather, Scrum says, "When you reach the end of the sprint, and work is not done, you are required to have a conversation about why and to reason, together as a team, about WHETHER and HOW the miscalculation should be avoided". Your manager changed the requirements? The API didn't support the feature you needed? Everybody should leave the meeting saying, "Yes, this was a special instance that could not be avoided, we will ignore it and carry on". On the other hand, if you have missed your sprint deadline by three points, three sprints in a row? You have to sit down in a meeting room and agree, "Ok, we actually aren't capable of 18 points a sprint, so from now on, we'll draw our sprint line at 15 points and see what happens".

He will be far more productive when he is in "the zone" and can focus at the best problematically path to reach that end-goal that encompasses all user stories. He will focus on hard things when he feels good and only do boring stuff when he feels in no not so good day. And that can change by the hour.

The only thing that Scrum dictates here is that you decide on the best path through your user stories in the interval planning meeting as a team. If there are dependencies in your stories, they must be ordered in such a way that the dependencies are respected. Additionally, there is the matter of regression testing to consider. You try to put the stories that need the most re-examination towards the top of your backlog. Code quality suffers if you don't, because if you pile up all of your "sure thing" stories at the front of the sprint, then you write a bunch of bulletproof code right away, and then, at the end of your sprint, you write a bunch of code that may have edge cases that you haven't thought about, and you only get to test it a day or two before deployment. This fucks your code quality.

He is faster because he does not get slowed down with internal communications and endless debates and team meetings. He is faster because he does not have to also know the other unimportant things for the current goal he needs to have right now. He is also faster because he can test multiple results in one test, while the SCRUM equivalent would be every test for every user story.

Scrum dictates a daily stand-up that is not permitted to take longer than 10 minutes, an interval planning meeting that may not take longer than an hour, and a sprint retro that may not take longer than an hour. If you are having more meetings than this, well, you aren't Scrumming. If you can't spare two hours and ten minutes a week to talk to your managers, then Scrum sure as shit isn't going to help you, but I don't know what else will either.

The issue here is that not every developer will be this effective. And you must also trust that developer that the outcome will be a success. But when the developer has a track history of near zero bugs and lots of success rates then you must trust this knowledge.

Correct. According to Scrum, there are several ways in which the engineer's knowledge may not be challenged, no matter how much the product manager wants to. In particular, if your engineer that has a track history of zero bugs and lots of success rates says, "This is not reasonable for us to complete in this sprint", then you are forbidden explicitly by the Scrum manual from even so much as needling him "but couldn't you try?". If you have ever, even once, been overridden on this point by your PM, you are fucking up Scrum.

Don't worry, at the end when the demo happens, you will still to test it the SCRUM way user story by user story. And you will still have the same unit tests and builds/deployments. Bit it will be highly optimized code, more reliable, less bugs and easier deployable.

This is a coded way of saying, "the results from scrum and from undirected development are indistinguishable, so long as you use stories with acceptance criteria to dictate work". I don't disagree.

But but but, how about transfer of knowledge? That is a none issue since good developers can jump into any project, focus on it and they will be up and running in a very short time.

This here is the most damning statement of all. There is a specific point to be made about Scrum: I should be able to walk up to any engineer mid-level or above (because juniors always need a little more guidance) and hand him one story, and my source code as it exists right now, and expect him to return to me a product with the new feature integrated. If you cannot do this--YOU GUESSED IT--you are fucking up Scrum.

There is no way in hell that, whatever broken, shitty process you're using, it's actually agile. It sounds to me like you are being strangled in process by managers that are abusing the rules to try to make it sound the way they want. I have two hours and ten minutes of meetings about my product a week. My engineers and I pick up whatever stories we want in the order we want, so long as it makes sense in the "order of stories"--as determined by US. That is, if I know that story C describes a feature that can only be reached by selecting an item from a list in feature A, then I have to wait for feature A to be written first. This is pure common-sense, there's nothing process oriented around it.

All you just proved to me is that you have a shitty process that somebody taped over the label of, and scrawled "SCRUM" in crayon over the front, and then went to their manager and declared proudly, "WE IS DOING AGILE NOW".

All this hostility aside, I feel sorry for you if these complaints are actually legit from your workplace. You should look for another job. It sounds like yours sucks.

Ok. I have eight engineers. We have one product. What EXACTLY are you suggesting? How do you want me, hypothetically, to instruct this other developer?

It sounds like you want me to dump a pile of design screenshots on a desk, for some arbitrary amount of work, and just wait for my engineer to get them done. Is that right?

Ok, ok, seriously though. What do you work on, and how many people use it? What is it for?

You can "call it" all you want. My team and I still use Pivotal Tracker all day, every day.

I can't hear you over the sound of hot productive my agile team and I are.

I own a product used by three hundred thousand people a month and work on an agile team with eight engineers. We love it. We push out great products every two weeks on the dot and we participate in the agile process to maximize our parallelism. Everybody can work on everything in the backlog at basically any time, because our requirements were clearly defined, agreed upon by all of us, and we push back in all the ways Agile suggests that we should.

You can't substantiate your claims. All you can tell me is, "NOBODY CAN DO IT EVERYBODY HATES IT RAH RAH RAH". You just don't know what the fuck you're doing, clearly. And/or your product manager doesn't.

What you're telling me is that you suck at understanding any problem whatsoever unless you are actively programming at the time. Why can't you look at a user story and the associated design of the page, and then tell me how you're going to write it? Are you trying to say that you're incapable of predicting anything at all ahead of time? Well, if so, you suck at your tools and you suck at development. You should ALWAYS be able to just rattle off, "Ok, this is about what I'm going to need to do in order to achieve this story".

"WHAT ABOUT EXPERIMENTAL FEATURES RAH RAH RAH" I hear you screech autistically.

Spikes! Spikes. Any agile practitioner worth their salt knows exactly how to handle this: you write a story to do just enough code writing, just enough technical investigation for a proof-of-concept or a skeleton implementation of the thing. If it makes sense to hold onto your branch and use it as the basis for the story, then have-the-fuck-at it.

I have taken the challenge. I've been on very functional agile teams, and I've been on reasonably functional non-agile teams. In non-agile teams, everybody has to confine themselves to separate locations in the app, or else merge hell ensues. In non-agile teams, you'll try to "boil the ocean", writing a smidgen of code here and a smidgen there, just sorta lumping together shit until you have the whole feature in place. And then once you do, how do you even know it really works? What about that edge case you introduced when you wrote three functions that "seemed exciting" early on and then you realized you had to spend half a day writing support and UI code before you could actually integrate and exercise them?

The most damning part of this whole thing is your complaints about SCRUM/Agile. You're bitching about the exact problems that Agile fixes.

You, sir, are just employed at a shitty job. Don't blame Ford when your cab driver drops you off two miles away from your destination after taking the long way there. The tools are fine. Your PEOPLE suck.

Yeah, see? That's you, or your product manager fucking up hard. Explain to me, please, what are the restrictions of SCRUM that need bypassing? If your SCRUM meetings are wasted, then what the fuck are you actually talking about in them?

SCRUM is a series of restrictions on how your product manager is permitted to interfere with you building great products. End of story. If it is functioning differently in your organization, then yeah, you guys are fucking it up hard.

How do all of you suck so hard at Agile?

I gotta say, I'm a huge believer in Swift. Disclaimer, it's the language I work in daily.

It lacks some things that truly functional languages give you, and it permits you to have state if you want it. But, the language uses COW through and through to give you efficient and powerful "value semantics" on larger stuff than ints and floats. The static analyzer and the rules about nullity make a lot of sense, and they provide a guaranteed crash-free experience with only a little extra work on top of the code for the naive case.

Ultimately, too, swift is wicked fast. It's sensible both as a server language and as a client side one, which I absolutely could not say about its predecessor. And IBM's offerings on BlueMix provide the infrastructure that you need to really say that "the industry is behind Swift on the server".

So, you get all the safety and fancy syntax of a new, modern language, but "C++ like" speed at runtime.

You, sir, are doing agile wrong.

Basic and visual basic. They were so watered-down that they were really for, "If you're never going to learn to write software, learn this instead, and you can get along".

XD

Have an upvoat.

Yes. Which is why, if you read the 13 page SCRUM guide, near the bottom of page 5, in the definition of the responsibilities of a 'Development Team':

They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;

The meaning of this is that if you say, "Hey, I think before we do anything else, we should fix this thing over here." And if the rest of the development team nods and thumbs-ups, then bam, that's written in as a technical task on a relevant story. That's where your 'senior engineer freedom' is.

So far as your comparison of good versus bad developers, I'll respond to each pair of statements.

• SCRUM Developer: "Sure thing! Put it in the next sprint, as close to the top as you think it has priority for."
• The stories in your backlog represent, "These are the things the program will do at the end of the sprint that it doesn't do now". All the other stuff you need to do, the development team puts into chores and bugs. These entries in the backlog don't have points, because they don't represent 'things the user can do'. And then, the development team decides whether they need doing. In SCRUM, the 'Scrum Master' is explicitly prohibited from overriding what the engineers decide is necessary to get the stories done. Fixing bugs? Absolutely. Paying down tech debt? You betcha. Et cetera.
• SCRUM Developer: "Ok, this is really important so we'll fix it right now, but at the end of the sprint, we should all understand that this is the reason velocity was low."

You're acting like the process of SCRUM is about laying out numbers and then telling a team they have two weeks to 'fit the bill'. That's just wrong, you've got it backwards. SCRUM says, "If you observe the people you're working with in this way, the numbers you get will be pretty reliable if you use them to inform your guesses about when things will be done". It also says that you just have to understand that you can't enforce changes to these numbers, you have to do that by dealing with the messy business of communicating, and collaborating, and figuring out what your team needs in order to do better. But, if your team chooses the right toolkit, and shares their knowledge, and leverages each other's strengths, and so on, these numbers will go generally up--and if your team sucks shit, these numbers will go generally down.

It sounds like you just haven't participated in a well-run SCRUM process. You have to understand--SCRUM only makes room in the backlog for stories with points, and only points count. But this DOES NOT mean that you should only ever be working on pointed stories! If you have a 'chore' or a 'bug', then just work on them instead.

"But my velocity will go down, even though I'm working hard!" True. You're still working, but the work you're doing does not provide new user-facing value. This is SCRUM accurately reporting that less of the work you did was feature-driven.

If your manager comes back and says, “look, your velocity went down, therefore, you’re not working as hard”... Then your manager is not doing scrum.

Yeah, I agree--phillips-head screwdrivers make really terrible hammers!

If your point is simply that most people tack the term 'SCRUM' onto a project and then manage it just like they always did--as if SCRUM were just some sort of tool like Excel--then I won't argue with you there. But, there seems to be a deeper misunderstanding of what SCRUM is and what it's for, which I'll try to address. And before anybody suggests that I'm just a manager fluffhead, no, I'm an engineer. I work in an agile environment and I've trained a couple of product managers in my time to SCRUM properly.

Why is SCRUM a project killer? Easy, it freaks the project managers and their managers out when their graph is showing that yet again they will fail in getting the next demo. And the last thing you want is a project manager freaking out and push the developers for yet another shortcut.

This is the point where I can see that somebody has missed the point of SCRUM. SCRUM says, "Look, you were going to miss that deadline anyway. But thanks to SCRUM, you are aware of it now." Specifically, the question is, what does the manager do when they see that, based on velocity, it looks like you're going to miss a deadline? If they are practicing SCRUM, there are two options. One, is to push back the release date. The other, is to remove features. And, very specifically--if your manager EVER tries to look at your timeline, and then "compress" it by making technical suggestions or asking the team to fish for shortcuts--then you have violated SCRUM and you've thrown away everything it can possibly give you.

Agile development is about responding to changing requirements. Ultimately, in the ideal case, it brings you down to making a releasable product improvement every sprint or three. It's also about reporting projections with mathematical frankness, which includes both the projection, and the awareness that the projection has uncertainty. If your product manager practices SCRUM correctly, then they'll go right to their own manager and say, "Ok, we're gonna deliver two sprints past our expectation." And when they're told that's unacceptable, they'll say, "Ok, cool. So, what features do we consider lowest priority?"

If you don't have a PM that will go to bat for you on those terms, then sorry--you aren't practicing SCRUM, you're just buzzwording your job advert.

PM me if you’d like. I’m a professional developer and I’m focusing on architecture for my “focus”. It’d be a great opportunity for us both. ^^

Yeah, I'm personally a big believer in the idea you should learn at least one "low level" language like C or C++. So many concepts that are sorta esoteric in high level languages make a lot of sense once you know where we were coming from.

Python is a good starter. I’d say consider ruby, too.

Code Reading: The Open Source Perspective

Reading code is more your job than writing it, and it's a big 'good to great' step. You wouldn't want to write professionally without reading the masters' works, would you?

That's fair. And then there's the intellectual load: it's much harder to determine if a function is throwing than if it's returning a value that may be empty.

Good advice, in most languages. I think something people tend not to understand about exceptions is how they tear open the logic of the application that throws them. It's often compared to a 'goto' statement, but since 'goto' is omitted in most modern languages and is pretty much useless, it doesn't get the point across.

tl;dr: Throwing exceptions allows execution to leave a stack frame without popping or pushing.

Code is just lots and lots of functions. Object-oriented languages will fool you, because they have all this nice syntax, but they're actually just making big tables of functions that take 'self' as a hidden argument, where 'self' is a struct that contains all your state (instance variables, etc).

So, when you call a function, the processor has to push all its state (usually just register contents) onto the stack, pass the function arguments (in registers or on the stack) and then advance the base pointer and hand control over to the new function. After the jump, the new function does whatever it's going to do, including maybe repeating this process for yet another function, and then each one "unwinds" the stack when it's done to hand control back to the caller.

Most implementations of exceptions jump out of the stack to wherever the handler is, which means, they have to figure out how not to explode the stack. That's pretty expensive. In good implementations, the compiler will optimize try/catch pairs pretty well, but in many implementations, even pretty basic throws cost a lot.

http://blogs.msdn.com/b/ricom/archive/2003/12/19/44697.aspx http://stackoverflow.com/questions/567579/how-expensive-are-exceptions http://stackoverflow.com/questions/891217/how-expensive-are-exceptions-in-c

As a corrolary, you should always be aware of the life cycle of the framework you’re using. Using iOS as an example, a “view controller” has some methods that are called exactly once, at least once, or every time a certain event occurs. The subtleties of these timings can be easy to miss and cause strange behavior.

I'm a full-time iOS developer, and we've been working Swift into our daily lives since 2.0 was released. The benefits are impressive, tbh, but I would caution you that it's very easy to write your Swift code in such a way that you don't really get as much benefit. What you want to do is really focus on learning as much about the Functional Programming side of Swift as you can.

You can approach Swift as just an object-oriented language that has really strong typing, and you get some benefits from Objective-C. But, it just feels like you're operating a language with a lot of heavy safety gear on. The strong typing is really meant to allow functional structures, like monads and higher-order functions. Even if you just sorta "get the idea" about how FP works and you try to use it to cut down the hairiness of your everyday structures, you'll see the benefits.

Functional programming languages are a big push right now. I wouldn't necessarily say that FP as it's always existed is going to be "the" paradigm of the next decade, but I can say for sure that embracing FP early seems (so far) to be very, very beneficial to one's career.

It just comes across that way because you're considering the frameworks. The frameworks were and are still written in Obj-C because there's just too much legacy code to snap one's fingers and re-make it.

Measuring competency is hard. It's the same sort of thing as asking a mechanic, "How much experience do you have with wrenches?" or, "How much experience do you have with jack stands?" It's wholly possible to work with C++ exclusively for ten years and still be bad at it. Furthermore, a good mechanic can get dropped into an unfamiliar shop, and within a day or two they'll be humming away nicely, where a shit mechanic would never quite get his footing no matter how much he's got going for him.

My personal recommendation, in this case, is to try to quantify your experience in achievements instead of in 'years' or 'volume' of experience. Providing specific examples of stuff you've done in C++, explaining the domain of the problem you solved--those things tend to be the things that really raise eyebrows.

For myself, for example, I would discuss my most recent work by saying that I 'began educating myself in functional programming as soon as Swift was announced by Apple, and began applying my knowledge to the app on which I work immediately. When Swift 2.0 was announced the following year, I applied its new features to the software I had been writing, and we began integrating my code as the basis of the application the day after Xcode 7.0 Final was released".

That explains how I recognized the applicability of a new tool to an old task, how I went about validating my knowledge while still doing my day job, and how ultimately my solution was recognized as useful by my colleagues and superiors and went into production. Soon, once we've released the code, I'm going to chase down some numbers about how my code's improved our stability.

In your case, as a consultant, I would go back and ask your clients. Ask them, "could you tell me a little bit about how the work I did on _______ project helped you out?" You'll find, if you've done a good job and worked with nice people, that they'll happily tell you about how you did great work that really helped their business. Then, somebody reading your code isn't thinking in terms of, "This guy gets up and running in new languages pretty quick, I bet he could handle this". They're thinking in terms of, "This guy boosted the profits of every company he worked with, and now he's going to boost mine."

This. There are some problems with object-oriented as a paradigm, and composition is an interesting alternative that has a lot of benefits if your type system can back it up. No individual paradigm makes 'the right' compromises in every situation--even as I'm driving toward protocol-based composition as my primary tool in Swift, I still am very glad to have good ol' classes around for a handful of situations.

I think that you should consider that, anywhere you have an inheritance tree deeper than three or four, you should ask yourself if you're encapsulating your variation correctly. Ideally, if you have fourth and fifth derivative objects, then they should spend most of their lives being treated as anonymous concrete instances of some superclass at the third or fourth level.

Oh yah, there is one, you just need 14 fingers to play it.

Good link! I personally found that the game-format made it stick, but yeah.

You have to unlock all the keys. You'll unlock the number-based motions in a later level. Keep at it though, the puzzles get pretty crazy! I've only made it just over halfway.