--- layout: post title: "Dependency rejection" description: "In functional programming, the notion of dependencies must be rejected. Instead, applications should be composed from pure and impure functions." date: 2017-02-02 08:56 UTC tags: [Software Design, Dependency Injection, F#, Haskell, Functional Programming] image: "/content/binary/unit-with-dependencies-and-direct-and-indirect-input-and-output.png" image_alt: "A unit with dependencies and direct and indirect input and output." --- {% include JB/setup %}
{{ page.description }}
This is the third article in a small article series called from dependency injection to dependency rejection. In the previous article in the series, you learned that dependency injection can't be functional, because it makes everything impure. In this article, you'll see what to do instead.
One of the first concepts you learned when you learned to program was that units of operation (functions, methods, procedures) take input and produce output. Input is in the form of input parameters, and output is in the form of return values. (Sometimes, though, a method returns nothing, but we know from category theory that nothing is also a value (called unit).)
In addition to such input and output, a unit with dependencies also take indirect input, and produce indirect output:
When a unit queries a dependency for data, the data returned from the dependency is indirect input. In the restaurant reservation example used in this article series, when tryAccept
calls readReservations
, the returned reservations are indirect input.
Likewise, when a unit invokes a dependency, all arguments passed to that dependency constitute indirect output. In the example, when tryAccept
calls createReservation
, the reservation value it uses as input argument to that function call becomes output. The intent, in this case, is to save the reservation in a database.
Instead of producing indirect output, you can refactor functions to produce direct output.
Such a refactoring is often problematic in mainstream object-oriented languages like C# and Java, because you wish to control the circumstances in which the indirect output must be produced. Indirect output often implies side-effects, but perhaps the side-effect must only happen when certain conditions are fulfilled. In the restaurant reservation example, the desired side-effect is to add a reservation to a database, but this must only happen when the restaurant has sufficient remaining capacity to serve the requested number of people. Since languages like C# and Java are statement-based, it can be difficult to separate the decision from the action.
In expression-based languages like F# and Haskell, it's trivial to decouple decisions from effects.
In the previous article, you saw a version of tryAccept
with this signature:
// int -> (DateTimeOffset -> Reservation list) -> (Reservation -> int) -> Reservation // -> int option
The second function argument, with the type Reservation -> int
, produces indirect output. The Reservation
value is the output. The function even violates Command Query Separation and returns the database ID of the added reservation, so that's additional indirect input. The overall function returns int option
: the database ID if the reservation was added, and None
if it wasn't.
Refactoring the indirect output to direct output is easy, then: just remove the createReservation
function and return the Reservation
value instead:
// int -> (DateTimeOffset -> Reservation list) -> Reservation -> Reservation option let tryAccept capacity readReservations reservation = let reservedSeats = readReservations reservation.Date |> List.sumBy (fun x -> x.Quantity) if reservedSeats + reservation.Quantity <= capacity then { reservation with IsAccepted = true } |> Some else None
Notice that this refactored version of tryAccept
returns a Reservation option
value. The implication is that the reservation was accepted if the return value is a Some
case, and rejected if the value is None
. The decision is embedded in the value, but decoupled from the side-effect of writing to the database.
This function clearly never writes to the database, so at the boundary of your application, you'll have to connect the decision to the effect. To keep the example consistent with the previous article, you can do this in a tryAcceptComposition
function, like this:
// Reservation -> int option let tryAcceptComposition reservation = reservation |> tryAccept 10 (DB.readReservations connectionString) |> Option.map (DB.createReservation connectionString)
Notice that the type of tryAcceptComposition
remains Reservation -> int option
. This is a true refactoring. The overall API remains the same, as does the behaviour. The reservation is added to the database only if there's sufficient remaining capacity, and in that case, the ID of the reservation is returned.
Just as you can refactor from indirect output to direct output can you refactor from indirect input to direct input.
Again, in statement-based languages like C# and Java, this may be problematic, because you may wish to defer a query, or base it on a decision inside the unit. In expression-based languages you can decouple decisions from effects, and deferred execution can always be done by lazy evaluation, if that's required. In the case of the current example, however, the refactoring is easy:
// int -> Reservation list -> Reservation -> Reservation option let tryAccept capacity reservations reservation = let reservedSeats = reservations |> List.sumBy (fun x -> x.Quantity) if reservedSeats + reservation.Quantity <= capacity then { reservation with IsAccepted = true } |> Some else None
Instead of calling a (potentially impure) function, this version of tryAccept
takes a list of existing reservations as input. It still sums over all the quantities, and the rest of the code is the same as before.
Obviously, the list of existing reservations must come from somewhere, like a database, so tryAcceptComposition
will still have to take care of that:
// ('a -> 'b -> 'c) -> 'b -> 'a -> 'c let flip f x y = f y x // Reservation -> int option let tryAcceptComposition reservation = reservation.Date |> DB.readReservations connectionString |> flip (tryAccept 10) reservation |> Option.map (DB.createReservation connectionString)
The type and behaviour of this composition is still the same as before, but the data flow is different. First, the function queries the database, which is an impure operation. Then, it pipes the resulting list of reservations to tryAccept
, which is now a pure function. It returns a Reservation option
that's finally mapped to another impure operation, which writes the reservation to the database if the reservation was accepted.
You'll notice that I also added a flip
function in order to make the composition more concise, but I could also have used a lambda expression when invoking tryAccept
. The flip
function is a part of Haskell's standard library, but isn't in F#'s core library. It's not crucial to the example, though.
Did you notice that in the previous diagram, above, all arrows between the unit and its dependencies were gone? This means that the unit no longer has any dependencies:
Dependencies are, by their nature, impure, and since pure functions can't call impure functions, functional programming must reject the notion of dependencies. Pure functions can't depend on impure functions.
Instead, pure functions must take direct input and produce direct output, and the impure boundary of an application must compose impure and pure functions together in order to achieve the desired behaviour.
In the previous article, you saw how Haskell can be used to evaluate whether or not an implementation is functional. You can port the above F# code to Haskell to verify that this is the case.
tryAccept :: Int -> [Reservation] -> Reservation -> Maybe Reservation tryAccept capacity reservations reservation = let reservedSeats = sum $ map quantity reservations in if reservedSeats + quantity reservation <= capacity then Just $ reservation { isAccepted = True } else Nothing
This version of tryAccept
is pure, and compiles, but as you learned in the previous article, that's not the crucial question. The question is whether the composition compiles?
tryAcceptComposition :: Reservation -> IO (Maybe Int) tryAcceptComposition reservation = runMaybeT $ liftIO (DB.readReservations connectionString $ date reservation) >>= MaybeT . return . flip (tryAccept 10) reservation >>= liftIO . DB.createReservation connectionString
This version of tryAcceptComposition
compiles, and works as desired. The code exhibits a common pattern for Haskell: First, gather data from impure sources. Second, pass pure data to pure functions. Third, take the pure output from the pure functions, and do something impure with it.
It's like a sandwich, with the best parts in the middle, and some necessary stuff surrounding it.
Dependencies are, by nature, impure. They're either non-deterministic, have side-effects, or both. Pure functions can't call impure functions (because that would make them impure as well), so pure functions can't have dependencies. Functional programming must reject the notion of dependencies.
Obviously, software is only useful with impure behaviour, so instead of injecting dependencies, functional programs must be composed in impure contexts. Impure functions can call pure functions, so at the boundary, an application must gather impure data, and use it to call pure functions. This automatically leads to the ports and adapters architecture.
This style of programming is surprisingly often possible, but it's not a universal solution; other alternatives exist.
Comments
Hi, Thank you for this blog post series. I also read your other posts on ports and adapters and the proposed architecture makes sense in terms of how it works, but I struggle to see the benefit in a real world application. Maybe let me explain my question with a quick example.
In the 2nd blog post of this series you demonstrated this function:
If I understand it correctly this function is pure if
readReservations
andcreateReservation
are both pure otherwise it is impure.I also understand the benefit of having a pure function, because it is a lot easier to understand the code, test the code and reason about it. That makes sense as well :).
So in the 3rd blog post you make
tryAccept
a pure function, by removing the function dependencies and replacing it with simple values:However this was only possible because you essentially moved the impure code into another new function:
So after all the application hasn't really reduced the total number of impure functions (still 3 in each case -
readReservations
,createReservation
andtryAccept[Composition]
).The only difference I see is that one impure function has been refactored into 2 functions - one pure and one impure. Considering that the original
tryAccept
function was already fully testable from a unit testing point of view and quite readable what is the benefit of this additional step? I would almost argue that the originaltryAccept
function was even easier to read/understand than the combination oftryAccept
andtryAcceptComposition
. I understand that impure functions like this are not truly functional, but in a real world application you must have some impure functions and I would like to better understand where trade-off benefit of that additional step is? Am I missing something else?Dustin, thank you for writing. There are several answers to your question, depending on the perspective one is interested in. I'll see if I can cover the most important ones.
Is it functional? #
On the most fundamental level, I'm interested in learning functional programming. In order to do this, I seek out strictly functional solutions to problems. Haskell is a great help in that endeavour, because it's not a hybrid language. It only allows you to do functional programming.
Does it make sense to back-port Haskell solutions to F#, then? That depends on what one is trying to accomplish, but if the goal is nothing but learning how to do it functionally, then that goal is accomplished.
Toy examples #
On another level, the example I've presented here is obviously nothing but a toy example. It's simplified, because if I presented readers with a more realistic example, the complexity of the real problem could easily drown out the message of the example. Additionally, most readers would probably give up reading.
I'm asking my readers to pretend that the problem is more complex than the one I present here; pretend that this problem is a stand-in for a harder problem.
In this particular context, there could be all sorts of complications:
-
Reservations could be for time slots instead of whole dates. In order to keep the example simple, I treat each reservation as simply blocking out an entire date. I once dined at a restaurant where they started serving at 19:00, and if you weren't there on time, you'd miss the first courses. Most restaurants, though, allow you to make reservations for a particular time, and many have more than one serving on a single evening.
-
Most restaurants have tables, not seats. Again, the same restaurant I mentioned above seated 12 people at a bar-like arrangement facing the kitchen, but most restaurants have tables of varying sizes. If they get a reservation for three people, they may have to reserve a table for four.
-
Perhaps the restaurant would like to implement a feature where, if it receives a reservation that doesn't fill out a table (like a reservation for three people, and only four-people tables are left), it'd defer the decision to see if a 'better' reservation arrives later.
-
Some people make reservations, but never show up. For that reason, a restaurant may want to allow a degree of overbooking, just like airlines. How much overbooking to allow is a business decision.
-
A further wrinkle on the overbooking business rule is that you may have a different overbooking policy for Fridays than for, say, Wednesdays.
-
Perhaps the restaurant would like to implement a waiting-list feature as well.
As you can see, we could easily imagine that the business logic could be more convoluted. Keeping all of that decision logic pure would be beneficial.Separation of concerns #
In my experience, there's an entire category of software defects that occur because of state mutation in business logic. You could have an area of your code that calls other code, which calls other code, and so on, for several levels of nesting. Somewhere, deep in the bowels of such a system, a conditional statement flips a boolean flag that consequently impact how the rest of the program runs. I've seen plenty of examples of such software, and it's inhumane; it doesn't fit within human cognitive limits.
Code that allows arbitrary side-effects is difficult to reason about.
Knowing that an subgraph of your call tree is pure reduces defects like that. This is nothing but another way to restate the command-query separation principle. In F#, we still can't be sure unless we exert some discipline, but in Haskell, all it takes is a look at the type of a function or value. If it doesn't include
IO
, you know that it's pure.Separating pure code from impure code is separation of concern. Business logic is one concern, and I/O is another concern, and the better you can separate these, the fewer sources of defects you'll have. True, I haven't reduced the amount of code by much, but I've separated concerns by separating the code that contains (side) effects from the pure code.
Testability #
It's true that the partial application version of
tryAccept
is testable, because it has isolation, but the tests are more complicated than they have to be:(You can find these tests in commit d2387cceb81eabc349a63ab7df1249236e9b1d13 in the accompanying sample code repository.) Contrast those dependency-injection style tests to these tests against the pure version of
tryAccept
:They're simpler, and since they don't use mocks, they're more robust. They were easier to write, and I subscribe to the spirit of GOOS: if test are difficult to write, the system under test should be simplified.
Hi Mark,
Thanks for your talk at NDC last month, and for writing this series! I feel that the functional community (myself included) has a habit of using examples that aren't obviously relevant to the sort of line-of-business programming most of us do in our day jobs, so articles like this are sorely needed.
We talked a little about this in person after your talk at the conference: I wanted to highlight a potential criticism of this style of programming. Namely, there's still some important business logic being carried out by your
tryAcceptComposition
function, like checking the capacity on the requested reservation date. How do you unit test thatreadReservations
is called with the correct date? Likewise, how do you unit test that rejected reservations don't get saved? Real world business logic isn't always purely functional in nature. Sometimes the side effects that your code performs are part of the requirements.The Haskell philosophy isn't about rejecting side effects outright - it's about measuring and controlling them. I wouldn't write
tryAcceptComposition
usingIO
. Instead I'd program to the interface, not the implementation, using an mtl-style class to abstract over monads which support saving and loading reservations.Code that lives in a
MonadReservation
context can read and create reservations in the database but nothing else; it doesn't have all the power ofIO
. During unit testing I can use an instance ofMonadReservation
that returns canned values, and in production I can use a monad that actually talks to the database.Since type classes are syntactic sugar for passing an argument, this is really just a nicer way of writing your original DI-style code. I don't advocate the "free monad" style that's presently trendy in Scala-land because I find it unnecessarily complex. 90% of the purported advantages of free monads are already supported by simpler language features.
I suppose the main downside of this design is that you can't express it in F#, at least not cleanly. It relies on type classes and higher-kinded types.
Hope you find this interesting, I'd love to hear what you think!
Benjamin
Benjamin, thank you for writing. The alternative you propose looks useful in Haskell, but, as you've already suggested, it doesn't translate well into F#.
I write F# code professionally, whereas so far, I've only used Haskell to critique my F# code. (If someone who reads this comment would offer to pay me to write some Haskell code, please get in touch.) In other words, I still have much to learn about Haskell. I think I understand as much, however, that I'd be able to use your suggested design to unit test
tryAcceptComposition
using theIdentity
monad for Stubs, or perhapsMonadWriter
orMonadState
for Mocks. I'll have to try that one day...In F#, I write integration tests. Such tests are important regardless, and often they more closely relate to actual requirements, so I find this a worthwhile effort anyway.
Hi Mark,
thanks for the post series, which I find interesting and needed. There is one part of your post that I find deserves further exploration. You write:
Firstly, I would say that you can write expression-based programs in any language that has expressions, which naturally includes C# and Java. But that's not particularly relevant to this discussion.More to the point, you're glossing over this as though it were a minor detail, when in fact I don't think it is. Let's explore the case in which "you may wish to defer a query, or base it on a decision inside the unit". The way you do this "by lazy evaluation" would be - I assume - by passing a function as an argument to your unit. But this is then effectively dependency injection, because you're passing in a function which has side effects, which will be called (or not) from the unit.
So, it seems to me that your technique of extracting side effects out of the unit provides a good general guideline, but not a completely general way to replace dependency injection.
Enrico, thank you for writing. There's a lot to unpack in that quote, which was one of the reasons I didn't expand it. It would have made the article too long, and wandered off compared to its main point. I don't mind going into these details here, though.
Direction of data #
In order to get the obvious out of the way first, the issue you point out is with my refactoring of indirect input to direct input. Refactoring from indirect to output to direct output is, as far as I can tell, not on your agenda. Designing with direct input in mind seems uncontroversial to me, so that makes sense.
No hard rules #
On this blog, I often write articles as I figure out how to deal with problems. Sometimes, I report on my discoveries at a time where I've yet to accumulate years of experience. What I've learned so far is that dependency injection isn't functional. What I'm still exploring is what to do instead.
It's my experience that the type of refactoring I demonstrate here can surprisingly often be performed. I don't want to claim that it's always possible to do it like this. In fact, I'm still looking for good examples where this will not be possible. Whenever I think of a simple enough example that I could share it here, I always realise that if only I simplify the problem, I can put it into the shape seen here.
My thinking is, however, constrained by my professional experience. I've been doing web (service) development for so many years now that it constraints my imagination. When you execution scope is exclusively a single HTTP request at a time, you tend to keep things simple. I'd welcome a simplified, but still concrete example where the impure/pure/impure sandwich described here isn't going to be possible.
This may seem like a digression, but my point is that I don't claim to be the holder of a single, undeniable truth. Still, I find that this article describes a broadly applicable design and implementation technique.
Language specifics #
The next topic we need to consider is our choice of language. When I wrote that deferred execution can always be done by lazy evaluation, that's exactly how Haskell works. Haskell is lazily evaluated, so any value passed as direct input can be unevaluated until required. That goes for
IO
as well, but then, as we've learned, you can't pass impure data to a pure function.All execution is, in that sense, deferred, unless explicitly forced. Thus, any potential need for deferred execution has no design implications.
F#, on the other hand, is an eagerly evaluated language, so there, deferred execution may have design implications.
Performance #
Perhaps it's my lack of imagination again, but I can't think of a well-designed system where deferred execution is required for purposes of correctness. As far as I can tell, deferred execution is a performance concern. You wish to defer execution of a query because that operation takes significant time.
That's a real concern, but I often find that people worry too much about performance. Again, this is probably my lack of wider experience, as I realise that performance can be important in smart phone apps, games, and the like. Clearly, performance is also important in the world of REST APIs, but I've met a lot of people who worry about performance without ever measuring it.
When you start measuring performance, you'll often be surprised to discover where your code spends actual time. So my design approach is always to prioritise making the system work first, and then, if there are performance problems, figure out how to tweak it so that it becomes satisfactory. In my experience, such tweaking is only necessary now and then. I'm not claiming that my code is the fastest it could be, but it's often fast enough, and as easy to maintain as I can make it.
The need for data #
Another concern is the need for data. If you consider the above
tryAccept
function, it always usesreservations
. Thus, there's no gain in deferring the database query, because you'll always need the data.Deferred execution is only required in those cases where you have conditional branching, and only in certain cases do you need to read a particular piece of data.
Even conditional branching isn't enough of a criterion, though, because you could have branching where, in 99.9 % of the cases, you'd be performing the query anyway. Would you, then, need deferred execution for the remaining 0.1 % of the cases?
Lazy sequences #
Still, let's assume that we've implemented a system using pure functions that take pure data, but to our dismay we discover that there's one query that takes time to execute, and that we truly only need it some of the time. In .NET, there are two distinct situations:
- We need a scalar value
- We need a collection of values
If we need a collection of values, we only need to make a minuscule change to the design of our function. Instead of taking an F# list, or an array, as direct input, we can make the function take a sequence (IEnumerable<T>
in C#) as input. These can be implemented as lazily evaluated sequences, which gives us the deferred execution we need.Lazy scalar values #
This leaves the corner case where we need a lazily evaluated scalar value. In such cases, I may have to make a concession to performance in my function design, but I wouldn't change the argument to a function, but rather to a lazy value.
Lazy values are deferred, but memoised, which is the reason I'd prefer them over function arguments.


About this program:
- Created for better programming on android tablet PC
- tested on Samsung Galaxy Tab SM-T110 and Medion LIFETAB S9512
Used Elements in this app:
- Folderpicker (by Steve Garman) taken from the DroidScript - Wiki
(modified by octazid)
- Methodfinder (by Steve Garman and Andreas Rozek) taken from the DroidScript - Wiki here called Functions Inspector
(modified by octazid)
- Colorpicker (inspired by the HexColorCode v2 from Schnee Wittchen) found in the DroidScript - Google Group modified and created as a single Dialog
(by octazid)


This model produces psychrometric data from the moist air model
in this library to be plotted in charts. The two most common chart
varieties are the Mollier Diagram and the Psychrometric Chart. The
first is widely used in some European countries while the second is
more common in the Anglo-American world. Specific enthalpy is
plotted over absolute humidity in the Mollier Diagram, it is the
other way round in the Psychrometric Chart.
It must be noted that the relationship of both axis variables is
not right-angled, the absolute humidity follows a slope which
equals the enthalpy of vaporization at 0 °C. For better reading and
in order to reduce the fog region the humidity axis is rotated to
obtain a right-angled plot. Both charts usually contain additional
information as isochores or auxiliary scales for e.g., heat ratios.
Those information are omitted in this model and the charts below.
Other important features of psychrometric chart data are that all
mass specific variables (like absolute humidity, specific enthalpy
etc.) are expressed in terms of kg dry air and that their baseline
of 0 enthalpy is found at 0 °C and zero humidity.
Legend: blue - constant specific enthalpy, red - constant temperature, black - constant relative humidity
The model provides data for lines of constant specific enthalpy, temperature and relative humidity in a Mollier Diagram or Psychrometric Chart as they were used for the figures above. For limitations and ranges of validity please refer to the MoistAir package description. Absolute humidity x is increased with time in this model. The specific enthalpies adjusted for plotting are then obtained from:
| Name | Description |
|---|---|
| Medium | Used medium package |


| Render Code | SHIFT + RETURN |
|---|---|
| Rotate XZ | Left Mouse |
| Pan | Middle Mouse or SHIFT + Left Mouse |
| Rotate XY | Right Mouse or ALT + Left Mouse |
| Zoom In/Out | Wheel Mouse or CTRL + Left Mouse |
| jscad | OpenJSCAD (native, import/export) |
|---|---|
| scad | OpenSCAD (experimental, import) |
| stl | STL format (experimental, import/export) |
| amf | AMF format (experimental, import/export) |


| Termination Notice From the client. |
|
To Madmec, I had issued you notice for termination of the project as the contract period is over and the site not functionally properly conformed by my attorney and many other users.All activities are to be ceased. All communication should be done by mail only with cc to my attorney<EMAIL_ADDRESS>The site you have created has lots of coding issues where proper coding was not undertaken causing glitch in the website causing frustration to the users and damaging the value of pic3pic and also causing losses to the owner (me) financially and emotionally. As of now I have no interest in taking the substandard product you have created. After a deep though and also consulting my attorney, I am come to the decision to terminate the contract taking my losses. I was advice to give you a mall to communicate the termination. If this mail does not satisfy. You will be sent a legal notice asking you to terminate the project. Site you have created is useless to me as it does not work properly. You stop all Hositing activites of pic3pic.com without demaging the domain name or creating any error on the DNS.Advance of Rs.72,000.00 you can keep it . I have no intention of keeping any more business relation with you. Any more communication please do through mail with CC to my lawyer. I hope you terminate the matter here itself without any more future legal action. Sincerly, |


C++ in Safety-Critical Applications - the JSF Coding Standard
|
|
JSF++ is a coding standard for use of C++ in safety-critical applications used by Lockheed-Martin Areo and others for software for the Joint Strike Fighter. The philosophy of JSF++ is basically an extension of C++'s philosophy to C. That is, by providing safer alternatives to unsafe facilities, you can avoid known problems with low level features. That is, programs should be written in a (safer) subset of (a better behaved and better-specified) superset of C++. The JSF++ is specifically designed to address undefined behavior and programming problems by restricting programmers to a better specified, more analyzable, and easier to read (and write) subset of C++. The idea is to eliminate large groups of problems by eliminating their root causes. For example, passing arrays between functions as pointers is simply banned, eliminating dozens of known problems. While allowing a large subset of ISO C++ features, the JSF++ is far safer than any simple C or C++ subset (e.g. MISRA C) could be. This talk presents the principles of JSF++ and shows examples of the use and implications of individual rules. |
|
MetroCon 2006 |
|
“Innovating for Society” |
|
Systems and Software Engineering |
|
Bjarne Stroustrup is the designer and original implementer of C++ and the author of "The C++ Programming Language" ( 1st edition 1985, 2nd edition 1991, 3rd edition, 1997, "special" edition 2000) and The Design and Evolution of C++. His research interests include distributed systems, design, programming techniques, software development tools, and programming languages. |
|
About the Speakers: |
|
Kevin Carroll is a Senior Staff Engineer at the Lockheed Martin Aeronautics Company. He received M.S. and Ph.D. degrees in computer science from Texas A&M University. Currently he is a member of the Joint Strike Fighter (JSF) Mission Systems Software Management Team where his responsibilities range from the design and deployment of reusable software components to the development of coding standards. In particular, he played a key role in guiding the Lockheed Martin effort to use C++ in safety-critical avionics systems on the internationally-oriented JSF program. |


2 types derived from SignatureCommandsBase
Microsoft.PowerShell.Security (2)
security\SignatureCommands.cs (2)
264
public sealed class GetAuthenticodeSignatureCommand :
SignatureCommandsBase
308
public sealed class SetAuthenticodeSignatureCommand :
SignatureCommandsBase


Louise Redknapp's lingering 'sadness' over Jamie divorce - and the regret that haunts her
It's been two years since Louise and Jamie Redknapp's marriage ended, but there are certain things she wishes she'd done differently
by Frances KindonThis time two years ago, Louise Redknapp was coming off the back of a painful separation from husband Jamie.
Isolated and frustrated by life as a stay-at-home mum, as their 21-year marriage collapsed, Louise moved out and bravely relaunched her own career.
But as well as finally embracing her true passion after almost two decades away from the spotlight, the past two years have also been fraught with devastation and fear for the star, who turns 45 today.
"I’m scared about the future. Jamie and I have got to a really positive place with each other. But I don’t know what life is going to be like," she told You magazine in March.
"I’m nervous about work and career and all those things, because I’m not young. And people are judgmental."
While she was the one who filed for divorce, the end of their seemingly rock-solid romance nevertheless hit Louise for six.
Admitting it came as a "shock", while she has never divulged the exact reason, she has been open about wanting to escape her "Stepford Wife" role.
With nothing to do while sons Charley, 15, and Beau, 10, were at school and forced to watch TV pundit Jamie live the life she wanted for herself, her self-esteem took a beating
That was until a 2016 stint on Strictly Come Dancing "put the fire" in her belly and inspired her to finally pursue her own dreams.
What followed was a successful stint in West End show Cabaret, followed by musical 9 to 5. And she's now got her comeback album, Heavy Love, ready for a January 2020 release.
However, she admitted she wished she had done thing differently. Describing her marriage to Jamie as "traditional", she kept her confidence crisis hidden, fearing those around her "would think I was nuts."
"I wish, three years ago, I’d been able to just speak up. For a long time it was easy to blame him," she previously said.
"But it was down to me to say, 'Something’s not right. My self-esteem is really struggling. I’ve got no passion. I wish I’d just gone, 'Right, the kids are getting older, and I love my job and I’m going to give it a real go, and Jamie, if you don’t like it, tough. But if you do like it, let’s talk about it.'"
Her biggest regret, she told the Guardian, was not opening up, because if she had then "at least I’d have known I tried."
And the pain of their split is something that will stay with Louise for the rest of her life.
"There'll never be a day that I don't feel sad about it because he was my husband for 20 years and the love I had for him will never leave me," she previously told Metro.
"But, I've had to pick myself up and find a better place and I'm definitely loving working again."
In spring she revealed she was struggling to move on, admitting it had been two years since she'd last had dinner with a man.
And she also struggled watching Jamie date women who looked like her - including model Lizzie Bowden who he enjoyed a brief fling with earlier this year.
“It is kinda weird! And then I start looking at them thinking, ‘Do they look like me?’ But he’s got his taste,” she told the Guardian.
However, if reports are to be believed, things are finally looking up for Louise after she was apparently spotted snogging model John Halls.
According to The Sun, she and the 37-year-old former footballer “were all over each other” and “snogging one another’s faces off” at Soho House last month.
They're believed to have had an 'instant rapport' when he auditioned to play her lover in her Stretch music video.
While she's apparently decided not to take things any further to save herself any complications, it'll be her sons who get the final call over any future boyfriend.
"What I will say is, if it happens, I’m going to be honest and open and embrace it. But my kids get the last say," she told You.


OS//OS 2015 will bring software developers, open government champions, changemakers and innovators together from across sectors.
We will celebrate and share global best practices, openly discuss the big challenges head on and build a community of people leading the way towards an open source future.
Expect inspiring keynote speakers, interactive workshops and plenty of opportunity for connection, participation & open knowledge-sharing with world-leading practitioners and the brightest local minds.
Feedback? Ideas? Questions?
We’re building this event to serve the community working to make the world a more open place. If you have ideas and feedback we would love to hear from you.
Our door is open: contact@opensourceopensociety.com


Simulated independent and additive effects of changes in wintering grounds habitat quality (i.e., reduced March precipitation; WQL), breeding grounds habitat quantity (reduced jack pine suitability due to climate [BQN‐C] or experimental plantations [BQN‐M]), and breeding grounds habitat quality (experimental plantations; BQL) on Kirtland's Warbler population dynamics
Each scenario involving reduced wintering grounds habitat quality was run with three levels of precipitation change: median change: −0.5%, lower 25th percentile: −32.0%, lower 10th percentile: −55.1%, based on an ensemble of 40 general circulation models and Representative Concentration Pathway 8.5. The contemporary model assumes environmental conditions remain the same on the wintering and breeding grounds, and thus serves as a null model for comparing impacts of climate and management changes.


Science festivals are vibrant expression of the cultural importance of science and technology of a nation. It gives scientists, inventors and researchers a chance to interact closely with students and citizens from all walks of life. Science festivals offer many different forms of engagement such as, lectures, dialogues, panel discussions and debates; through handson demonstrations, shows, exhibitions, and workshops; in form of science-related theatre, cafes, music, and stand-up comedy. The goal of the science festivals is to engage citizens with science in ways that are inspirational and empowering. Science festivals are the inspiring celebrations of the fascinating world of science and technology.
India International Science Festival (IISF) launched in 2015 is a celebration to promote Science and Technology and demonstrate how science could lead India towards a developed nation within a short span of time. The aim is to engage public with science and celebrate the joy of science and show the ways how science, technology, engineering and mathematics (STEM) provide us with the solutions to improve our lives. Ministry of Science and Technology and Ministry of Earth Sciences in association with Vijnana Bharati (VIBHA), has created a unique platform of India International Science Festival which intends to inspire curiosity and make learning more rewarding.
The goal of the Science festivity is to help youth, develop 21st century skills, with a focus on scientific knowledge, creativity, critical thinking, problem-solving, and teamwork. One longterm objective is to encourage students to study and work in scientific fields. The focus on the myriad faces behind some of the fascinating discoveries will inject scientific attitude in the masses and will give us the power to create new possibilities. Once we get young people interested in acquiring new knowledge, asking questions, and starting the quest for the answers, we will accomplish our goal. IISF is a science outreach marathon not a science sprint. We hope, this effort will fuel India’s drive toward becoming Vishwa Guru.


chunk_reveal.Rd
Function takes code from referenced code chunk and returns partial code sequence to series of code chunks separated by slide breaks. Upon compiling you get step-by-step code walk-through.
chunk_reveal(chunk_name = NULL, break_type = "auto", left_assign = F, left_assign_add = NULL, lang = "r", omit = "#OMIT", code_seq = NULL, code_seq_lag = NULL, code_seq_lag2 = NULL, code_seq_target = NULL, code_seq_start = NULL, func_seq = NULL, num_breaks = NULL, display_type = c("code", "output"), title = "", md = NULL, md2 = NULL, replacements = NULL, replace = NULL, replacements2 = replacements, replace2 = replace, replacements3 = replacements, replace3 = replace, widths = NULL, float = "left", chunk_options = "", color = c("black", "black", "black"), font_size_code = "80%")
| chunk_name | a character string referring to the name of the source chunk for the flipbooking |
|---|---|
| break_type | "auto" is default finding appropriate breakpoints, "user" can be used with the special comment message #BREAK within the source code chunk, "non_seq" can be used for non sequential display of code with special comment messages #BREAK2 (will show in second frame) and #BREAK3 (will show in third frame), an integer input can be given too, to simply display the source code chunk multiple times which is appropriate for observing multiple realizations of sampling, "rotate" allows cycling through different lines of code, the comment #ROTATE is used for lines to by cycled through |
| left_assign | a logical, default is FALSE, if TRUE will print the object created in the upper left hand corner of the source code chunk at the end of each partial reveal |
| left_assign_add | a character string containing function for table formatting in output, for left assign case only |
| lang | a character string indicating what programming language will be used. "r" is default; "python" is experimental |
| omit | a character string, as a comment, indicating lines that should be omitted, defaults to "#OMIT" |
| code_seq | a list of code as character strings, the list will automatically be created based on the previous three arguments or the user can input code manually |
| code_seq_lag | a list of code as character strings, lagged, the list will automatically be created based on the previous three arguments or the user can input code manually |
| code_seq_lag2 | a list of code as character strings, twice lagged, the list will automatically be created based on the previous three arguments or the user can input code manually |
| code_seq_target | a list of code as character strings, the length of code_seq, but only containing the last element of code_seq |
| code_seq_start | a list of code as character strings, the length of code_seq, but only containing the first element of code_seq |
| func_seq | a character string with function names; default is NULL and will reflect whatever function is highlighted from the code sequence |
| num_breaks | an integer, automatically calculated based on the length of the the code_seq list |
| display_type | a character string vector, the default is c("code", "output") for code and output to be displayed side-by-side, "output" will create spawned code chunks to only display output, "code" will create spawned code chunks only to show the partial code builds; "func" and "md" may also be displayed |
| title | a character string that may contain a title for the frames of the flipbook; this may included header info "## My Title" for example is a second level markdown title in Xaringan |
| md | a character string vector that contains markdown; each element will be shown on a separate slide in the display panel "md" (see display_type) |
| md2 | a character string vector that contains markdown; each element will be shown on a separate slide in the display panel "md" (see display_type) |
| replacements | a character string vector to be replace the string indicated by the 'replace' parameter |
| replace | a character string to be replaced in the input code sequentially with the replacement vector elements |
| replacements2 | a character string vector to be replace the string indicated by the 'replace2' parameter |
| replace2 | a character string to be replaced in the input code sequentially with the replacement2 vector elements |
| replacements3 | a character string vector to be replace the string indicated by the 'replace3' parameter |
| replace3 | a character string to be replaced in the input code sequentially with the replacement3 vector elements |
| widths | a numeric vector containing relative widths for panels |
| float | defines css float parameter, defaults to "left" |
| chunk_options | input 'knitr' code chunk options as a string, default to empty string "", useful input might be "fig.height = 4, fig.width = 3" |
| color | defines css parameter, defaults to "black" |
| font_size_code | this ain't working yet! |
a string object is returned will only work in 'knitr' context


Always helpful to have a basic refresher on the big picture of the web. In the end its basically a big retrieval system where we enter a url to send our request which is an HTTP Request to servers aka more computers to retrieve the HTML documents that are then displayed in our browser.
Tags + attributes = elements. Tags are simple instructions or signposts informing your computer how
you want it to handle the text or image or link between them. Although
I've been familiar with tags for a long time I never understood what
a void tag was. And this overview helped solve the mysetery of the break
br
tag. And the img
tag. Some examples of the tags are covered are below.
HTML attributes (atrribute is a property of an HTML element) Some html elements with attributes include:
Inline vs block elements. Inline elements do not break the text into chunks almost like a string of typed text.
Block elements create an invisible box around the text. Two important ones mentioned that link up with CSS are
span
and div
.
Glad to hear this final message. I can give myself a sigh of relief in knowing that I don't have to memerize every tag. Also this stuff changes rapidly. That mention of HTML 5 was a little clue.