So thank you for the opportunity to make this presentation to you all, and I hope it's of interest. So as I said, the International Acre Initiative is short for atmospheric circulation reconstructions over the earth. So I've got the next slide please. So Acre is a grassroots as a bottom up initiative that's marshaled together the international weather and climate data rescue and science communities over the last 14 now nearly 15 years. It's very much an end to end initiative and it links together three elements. International historical terrestrial marine weather data rescue, especially prior to the 1940 50s 60s, we tend to focus for that period. And that's daily, sub daily synoptic scale, weather data from land and from sea. Then the third pillar of element that's linked together from this and you see the diagram that follows the sticks in the net with which we follow with the next slide is that it also has the dynamical three dimensional reanalysis and weather reconstructions. And then finally, to take both the data and the reanalysis outputs is weather reconstructions and then make them available to users to climate services, applications, communities, etc. And so, as has been said in introduction, it involves recovery imaging scanning digitization and curation of these data was far back in time as possible. So said they're fed into international repositories that hold these data. And this enhances or hopefully enhances the weather mountain quality and quantity of these weather observations, going back through time which could be used for reanalysis or for any other purposes for that matter. And these are freely available to the full range of global climate services applications. But we're also working and have certainly for good part of the last eight years or more perhaps with social sciences humanities disciplines to try and meld together the weather reconstructions the reanalysis with climate histories the historical climatology and other elements so that we can capture the the environmental the social the biological the all of these elements that are going on in the system through time and how they can be put them together with the reanalysis to get a better product. So we don't just have a physical reconstruction the weather, but we have all sorts of information that helps us to understand the impact of that weather in the wider social and economic and environmental sphere. So let's synthesize this in a bit on the left hand side to data rescue there a massive effort going on there. Going from traditional king or digitization of marine and terrestrial data, right through to cloud source and citizen science approaches to to this, which of course they come very big across all sorts of disciplines in more recent times. And so it's bringing those sort of techniques together so we go from if you like, industrial or sort of cottage sort of scale one or two people digitizing right through the industrial scale digitizing right through the citizen science so we're pulling together all sorts of aspects to capture all this data, and going to national repositories I mentioned a couple the ICADS glamour by codes co ads glamour and ISPD, then feeding through to reanalysis, the one we particularly have been working through since the start is this 20th century reanalysis, it's a bit of a misnomer because it goes from 1906 to 2015 at the moment. And this is a global reanalysis, and it actually puts out more than one realization to be through to 80 realisation starts the model slightly different starting period of times. And therefore, you have these number of realizations of what the reconstruction of the weather. It's on the grid that it's mentioned they put 75.75 spatial resolution so feeding the data into this technique of reanalysis and then distributing it out both in terms of the actual reanalysis as the 20th century puts it out, but also we can downscale it. The better office place approaches being used and others can be as well. The enhancing the reanalysis I mentioned bringing together more the wider social, social sciences, disciplines, etc, trying to understand what more we can add to improve the wider scope of this reanalysis on this output, and then making it available to users. Next slide please. So in addition to providing this sort of international umbrella for data rescue activities. Acres developed a number of individual regional data rescue foci. You can see a list of them there covering various parts of the world show a slide in a moment which gives you the visual on that, but also important to note that Acres supported by major international bodies. It's a global organization, G cost WCRP, GEO, global framework for climate services and many others. So over that 1415 years that Acres has evolved. It's been linked in works with more and more of these, these bodies, and does get some funding from funding and personal is the biggest task that we have in sustaining that over time. So the next slide. Thank you. Thank you to the ACA and other data rescue efforts that Acres links into so in blue text and in shadings. You can see the various ACA regional focus, the Arctic, Canada, the Pacific, even the whole global oceans as make your oceans there, South Africa, Chile, Argentina, etc, etc. And other projects that they link into just showing in yellow there with the black text that we work to try and maximize our efforts and to sort of avoid duplication where possible. So it's it's working on a very much an international scale, but being able to get down to regional scales as well and to work with the those in those regions, so that both both benefit both Acre and those who are working in those regions from all sorts of different sources. So the next slide. Thank you. So some of the sources terrestrial instrumental weather observations just very briefly. There's a lot of early efforts in Europe in the late 18th century from Germany and France and other places to try and bring together networks of data for meteorological data. And previous to that in Italy in the 1600s, that's where it all started they were the first to try and develop networks within the Italian sort of what wasn't Italy then but within that region. But then we also get data from National Met Services, many since the 1850s or later. And others observatories, there are medical sources, military, Royal Engineers Army Medical Corps missionary data, consular data, lighthouses, port authorities, general publications, diaries, newspapers pamphlets, government gazettes journals, etc. Things like botanical gardens, signal pilot stations so wide variety of sources because in the particularly with a lot of these in the colonial era. The efforts for recovering what we important meteorological data that we're after could be in any sort of different source they wouldn't necessarily been a national met service certainly before the middle of the 19th century. And so you have to look to this wide range of possible sources and others to be able to recover the data that you're after. So we go to the next slide please. This is the marine side of things. There's a lot of books whether they be merchant shipping companies naval expeditions surgeons journals on the ships remarks books is a hydrographic and naval surveys that were done and private diary so mixture of things again to try and recover data. The next slide. I mentioned citizen science as one area where we've been looking at in more recent times to be able to address the whole digitization, you know the mass digitization of data and I put a few of them up there began on the top row there with old weather. Elements of old weather wailing and other elements which were some sort of sets that were developed to focusing on particular sources of data was what in Australia called weather detective 2014 to 2017 is funded by the Australian Broadcasting Corporation the equivalent of the BBC in the UK. But then we've got other ones on the bottom there there's something with Southern weather discovery out of New Zealand on the far left. UK tides from our title colleagues and sea level, trying to get them involved in from their own sort of sphere involved in data rescue. This is one of the most recent efforts where the rescue where the rescue to see led by Ed Hawkins University of Reading, and most recent one of the most recent ones is by our acre Argentina colleagues. This is on the first ones, which has actually been tapping more than the English speaking populace if you like in the world. This was, it has a Spanish as a Spanish side obviously. So some of the data that's gone into things like I co has international comprehensive ocean atmosphere data set. This is the least three and new ones sort of about sort of Philly soon I think, but shows you some of the things that I can contribute to that expeditionary data on the top left hand panel there English East India company logbooks. And they're showing that both in the time on and spatial distribution of this material. And on the bottom left hand side there Australian abstract logs. This was from the person who was the Clement rag who was the colonial meteorologist instead of Queensland and for some reason he got into getting data from ships in the late 1890s etc.  And then if it's on World War one that we were looking at that sort of particular period, and you have some links there to do that you can follow up when if anybody wants to after this presentation. So we go to the next slide. There's more of this sort of data this came out from the Indian Met Department. And a guy called Elliot is a John Elliot he was the second, so the third way second, get a right a second British director of the Indian Met Department. And for some reason he he was really getting into the wider sphere of things beyond India. So it got into the 1890s and there was a set of data in the books there which had this marine data over that I'm showing here. This is this is the raw coverage each of those years from 1993 to 1999 so some dots over the land that we have subsequently sorted out because of problems and that is in longitude that were wrong and incorrect. They cut off unfortunately at 10 degrees south so we miss out on some of the stuff there, but another layer of information that we can bring to bear on things. So the next slide please. So some examples of region activities like a foci chapters that that are ongoing so we have the next slide. So Acre Australia as an effort that's been going for a while now. A lot of logos there showing various bodies to see so I used to work and various efforts going on. A lot of it led led by my colleagues of the Linden Ashcroft and Joe August in Australia in the Bureau of Ethology and in the Canberra at the Australian National University and Christopher Minsky University Southern Queensland. So, you know, so a lot of things being brought together by these people who are folk high who leave this effort in in the Australian region, and just these maps on the right hand side just below the map of Australia that you might see in Australia's 1879 to 1881. This was showing us on the before and after map where the yellow dots and shading are where data has been brought in. And the thing was that the one lot of people who are working on this out of my hometown of Adelaide and the Bureau of Ethology there were volunteers who were digitising a lot of newspaper and all sorts of stuff for us and they wanted to know what difference does their effort make. So actually got us thinking more about that and so these two maps are to show before their data was available and after and you can see there's basically nothing or very little before and then much better later on just for that one spot time in space and time. So, again, the importance of getting more data and getting people to to work with you on this. So the next slide please. So this is one of the efforts under the Acre Australia's Acre Merit, my colleague Matt Benoy out of the Adelaide region office. And these are some of the things that they've been doing over the years for us as well as doing the things out of newspapers, old Adelaide registers that they've recovered going way back lighthouses, not just in South Australia but in Queensland the Ross Bank one there observatory. Old maps, whether maps they're the top right hand corner there for about 1879 65,000 maps that scan and got information from and things like that so a plethora of information that's being pulled together by various components and since it's just within the Australian situation. So the next slide please. There's one in Australia that I've particularly been interested in two lighthouses near the town of Albany in Western Australia the point King and break sea island lighthouses. So next slide. Thank you. So Western Australia in the middle exit on the map. The points in break point King and break sea island lighthouses are showing just the red they were so close together they're all coming together in the bottom southwestern corner of Western Australia. I pointed to a more detailed map of King George sound I think after Sydney Harbour it's putting on the biggest setting in Australia is the biggest harbours that exists that's actually bigger than Sydney Harbour. And so this is important one and they see the location of the two lighthouses one on the coast which is actually near Albany on the left and then one on the island of breaks the island out there. They were built by convicts and they cover period from 1861 onwards point King goes to sort of early in the 20th century very early. And then Peter's out you can see it's a ruin on the first of those pictures of it breaks the on has continued on, certainly into the 1920s. And we've begun digitizing these data we've, we've done a lot of the point King data. And we're still now working on the break sea island and these will be very valuable because of course you got ships coming across the old days from across the Indian Ocean, etc. And a very valuable effort that we're, we're trying to put together a potty get a paper on this to show it. The interesting thing with these in particular is that we discovered them bound in with the actual ship logbooks in the Met Office's archives in the UK. And as far as we know, certainly that 19th century part of the record. Basically, it's the only record of it doesn't exist in Australia. It's only exist there and so these are the sort of things you have to tease out sometimes maybe a little bit of detective as well as a climate scientist, etc. So interesting past perspective in terms of finding data with these particular lighthouses to the next slide please. So quickly some of the Southeast Australian lighthouses the next slide. I won't go to too much detail here but you can just see there are a lot of points here. Those with these big, these blue sort of filled in some star things. They're ones that we've had digitised or in the process being digitised I mentioned sort of some of them earlier. I'm sorry the other way around the red ones have been done and the blue ones haven't been done yet. So we're still going to address some of those and you can see there are a number of locations there that we can get them and go back through time they're going to be very valuable. So the next slide please. Just a bit on Perth in Western Australia has been an effort to push that record back and working with my Australian colleagues I was able to discover that there were data in Perth in Western Australia back to 1830. So the next slide. Thank you.  And you can see here this is just the pressure. This is the pressure data from 1830 from various sources that our Australian colleagues have got into and discovered that help us to develop a long series of observations and says pressure here will have temperature etc. And so a very, very valuable set this is only able to October period, but we have it for the full full year. So again, you know, pushing things back further and trying to get long records. Next slide. Thank you. So I can Antarctica. This is one of two. I can read your efforts run out of New Zealand out of near in New Zealand by my colleague Drew Laurie. There's also a Pacific. We got the next slide things. So something with the discovery which is one of the things I mentioned they've been doing this is a citizen science efforts capturing all with the data. If you go into cop at cop 26, I can have an event there. And it's a listening to the video. So if you wanted to look at the whole thing, including Southern with a discovery of it. You can you can look at it there. So the next slide. Thanks. So another thing just getting just showing examples from the the weapon with acre Antarctica. This is the data was recovered of the male ship SS. Discover 20 circumnavigations between 1885 and 1893. And these are coming up to the UK. To Australia. The bottom left hand thing. And then going on from Australia, New Zealand and the South America and back to the UK. So these are very valuable in recovering high latitude Southern hemisphere data. And these the sort of data is like gold dust. So next slide please. I guess South Africa is another effort that's that's that we've been doing an original basis. So some funding from Copernicus and from the Newton fund and from WMO. And this is just a snapshot of some of the data that's being worked on the yellow ones that we've recovered digitized so far as yellow text font shaded data runs. So there's all sorts of interesting things there. The various places shown in black there, Central Ireland, St Helena Capewood, hope, etc. Ranta Zanzibar, where they have what a call whether existed in the past called stationary ships. And these ships were left in Harvard for it could have been weeks months years decade even. And hopefully they recorded meteorological observations while they were there. And some of them listed on various places. So we're working to recover what we can have the meteorological observations from those sources because they're extremely valuable. The ones over the continent red that we're working on also and then blew a whole series which were from a South African meteorological commission back in the 19 about half the 19th century, which I'll say something about a minute. So if we go to the next slide. So this is work that was done to recover data from the Cape Town Observatory by my colleague, Stephen Robbins people in Acre, South Africa. And this has been published as an example here reconstruction of coal on the bottom right hand corner there reconstruction of coal weather frequency over South Africa from 1834 to 1899. It's right through to present time. They even got some in the first half of the early parts of the 1818 20s 30s, etc. Little bits and pieces that they are putting together and hopefully better get this record extended even further. So it will, though Perth is a nice one for making dirty and great one. This will perhaps me and supersede it but all these long records are extremely value if you're trying to build up picture what's going on and feed data into the reconstructions. So next slide. Thank you. And this is some of the work they've done over 1.5 billion entries in the last three years or so. And then those those commission reports that I mentioned to you these are made in 61 to 1908. The monthly data is available in published books and things like you can see on the bottom right hand there. But the problem has been finding the daily or sub daily. Now though this isn't exactly to do with commission that one that's in the middle there where it shows. This is the sort of thing that we've actually found that a lot of these daily sub daily data is actually in the newspapers, which is really great. But the quality of them varies and that's a really good image taken a scan from a newspaper. Some of them are just about illegible. That's really frustrating because they could be the only source we're going to get for this daily sub daily data. So again, there's a lot of work done in trying to tease out the information we want from various sources. And there's not only newspapers that looked at ship logs, but even farm diaries. My colleague Stefan is actually away from Johannesburg at the moment to be the farmers out in the various parts of South Africa to try and get old data from farmers. So the next slide please. So other ships we might want to look at. So next slide. So cable ships, I won't go into details, but these are ships that laid the original cables for the telegraph. Of course we know much more fancier situations than that, but they're extremely valuable because they go across a certain lines. They have to come back and check them every so often they can be breaks in it. So there are potential to get data from that. And we've discovered that the cable ships it's the engineers logs that the instrumental observations that somebody time scales are held. We also get sub daily water temperatures and salinity measurements down to the bottom where the cable is on the city on the in that sort of vicinity. And so these things are extremely valuable and we've been searching for them. Some of them are online, which you can scan some are held by the issues civil engineers in London. Some are actually the National Maritime Museum and Greenwich we nearly need to be able to push on this because these could be again a very valuable source of data. So the next slide please. So package ships, these are male ships, hence the term packet. So these are British ships which went out of Falmouth. Now the map in the middle shows a picture of those that went across the Atlantic to the Americas and across the South America and even to the Mediterranean. But there are a lot more, a lot more of them and they go to all sorts of places, West Africa, Cape Town, Australia, New Zealand, et cetera, et cetera, Valparaiso. And so we really need to get at this data. It's been frustrating because the few that we have found of packet ships generally tend not to have meteorological observations in them. But we're encouraged that the there are a set of these things in the UK Postal Museum. And the catalogue there covers about 1839 to 1929. And it says that it contains names of packet ships, dates, times of ships to purchase and arrivals and any observations made during the journey. So we have our fingers crossed that includes meteorological observations. So there's another one we have to get at. And some of them are also held again in the National Maritime Museum in Greenwich. So the next slide. So also we find ships going up rivers and such. And it's mainly in China, also I guess in the Amazon, but mainly in China where we've been able to get some data and pick the up the Yangtze. The Yellow River is apparently not particularly navigable, but beyond certain point. But the Yangtze is and actually goes right up from Shanghai right up to Chongqing. You might be able to pick out one of the diagrams there in the middle of the slide, which shows the river. So it's a good part of the river going into China where these ships were able to get to and obviously back in the day, the colonial period, you know, they were policing their situation there. So you had colonial gunboats and all this sort of stuff. So there's a thing called the Yangtze patrol, which is run by American interest 1854 to 1941. And so we've been getting data out of that and of course the Royal Navy from 1965. So we've been patrolling these rivers, some in this couple right in the southern part of China and also not on the bottom. There's a couple in Vietnam that we need to perhaps look at. So these are very vital sort of information, but we're also trying to track down what other nations all of them had a most nations at the time had a hand in various parts of China. So where are the German, French, Italian, Japanese, Austro-Hungarian, Portuguese, Russian log books from ships like this because they'd be extremely valuable. You also get them from expeditions, historical expeditions. So particularly when they're really early like this, they're extremely valuable. There was one in the Congo River about in 16 and we're hoping to get some data from that and then looking into that. And as you can see on the top side, the Congo goes quite a way into parts of Africa. So again, a very important one to get. And then the Niger River one in 1841, again shown in the slide there, vital to capture stuff data into the parts of the country where sometimes there's not any terrestrial data or very little. For the next slide. And finally, African steamers on Lake Malawi, often going up to service the missions around that lake. And so again, we're trying to track those down and see, did they have any meteorological observations on them, because they would be extremely valuable. The next slide. So another project that I've taken me about eight or nine years to get this going, all sorts of online games with illustrations and net services and goodness says what is something called the Mauritius project. So we're covering it in the chicken are coming, et cetera, the usual story of all weather observations. And there are a couple of sources that are very valuable, particularly the first one. These are extracted ship logs in 188 volumes, like Charles Mildrums journals from 1853 to 1914. He was one of the instrumental people and setting up the net society in Mauritius one of the earliest ones outside of Europe. And so that and for whatever reason, he began to have a very strong interest in ship log books. And we don't know whether his idea or where he got it or where we got it from somewhere else. But what he used to do is to send his people down to the harbor put Louis on Mauritius each day to ask the ship captains if they could come on board and transcribe the weather observations out of their logs. And so he's recovered, you know, this is an amazing data set for the Indian Ocean, extremely valuable, because we believe that the bulk of these log books may no longer exist. So the only source could be from his extractions. They do also have ship log books 1848 1874 to get a terrestrial weather observations from Richard itself, going way back into late 18th to early 20th century. So the next slide please. So this is a map of Mildrums on the 1st of January 1861, showing the Indian Ocean in the wider region. And they won't be able to see it exactly. There's two to two slanted detail. But if you can see the black lines and sometimes you'll see the arrows on it. These are the ship observations coming across the Indian Ocean there and even around Southern Africa there. And the lines they sort of iso lines isobars Mildrum was attempting to draw isobars from the data that was on those ships and show it graphically. Now, the problem was, he only managed to publish the first three months of 1861. And after that, they ran out of money and he basically says some stage of 13,000 maps and I have no money to publish them. Fortunately, those analogical journals from which this drawn on drawn have survived that they can be in burning quality. And so these are vital to be covering that so another layer of information over the Indian Ocean in this case. Next slide please. And just to show you some of the wider implications from this. I discovered that I was working on the data that's so far been done from around the 1870s. And I found about 50 or 60 ships from different nationalities, which were going on what's called the glano trade, the fertilizer trade from South America and Pacific there. Back to other when someone went through Mauritius, obviously that's where we'll have the data. But others were going back to Europe, etc. to provide this vital fertilizer for crops. And this is the bark James Henwall in 1871 in the Australian Australian shows that Oscar summer of 1871 so they're going around Cape Horn up to the Cape of Good Hope and eventually we'll go on to Mauritius to Mauritius. The interesting thing is this passage across the Southern Atlantic, and my tame naval historian, Clyde Wilkinson looks after Acre Ocean said well, there's very little data across this region and some of these times and so these are very valuable data and you can see down the bottom left hand corner, the pressure in blue and the temperature in orange from that particular voyage now it's not quality controlled or anything but it's just to show there is information there. The next slide is the only as the other one on the other one I'll show you, but the interesting thing about this one, this went through around Cape of Good Hope, South Africa, etc. to Mauritius in the winter of 1871. Now you can imagine going around Cape of Good Hope in the winter. I don't think I want to be doing it. Thank you. But again very valuable data and you can see again the trace we've got from that so again another example of information that can be gleaned. In this case beyond the Indian Ocean as it turns out, because of the nature of where this was going and the fact that they actually recorded. So the next slide please. So another source like this of marine data are settler and convict ships going out to Australia and New Zealand in the period from the late 18th to the 1867 I think was the last convict ship went out. So next slide please. So what we discovered was that the Royal Navy Medical Officer Surgeons, the Surgeons General Surgeons journals on these ships which are held by the ADM which is the Admiralty Records in the National Archives in the UK. We discovered that they often, well, not as often as we would like, but often enough to make it useful. They actually sometimes tabulated not just all the horrors of the looking after people with all sorts of medical conditions, convicts, etc. and pretty squatted conditions, but also sometimes the meteorological observations. And that's what's shown in the middle. And then you won't be able to see it, but there's a sort of light red is where they've written in the meteorological observations and I've shown a highlighter there, a barometer reading and a temperature reading. So they can be like this, so we have to be drawn out of the text, or sometimes you have people who you praise most highly, who did beautiful tabulations of all the data, everything you want, and you know presented it in their journals. And I think there's some of the 600 odd ships that went out to Australia with convicts. And of them, we've found about 150 odd have temperature observations. Now, often it's temperatures in the ships, you know, in the Surgeons rooms or in the bowels of the ship, but sometimes they're on deck as well. So we might be able to get something out of that, about a third of them 156, sorry 50 or 60 of them have atmospheric pressure, which is very vital for the reanalysis. So some daily observations usually. So, we've been looking at that. And we have at least from 1816 to 1867 that the Wellcome Trust did scan this material and so it's available online we can use it. Next slide please. Just some examples of ships again this is a convict ship, the ship Albion in 1828 so very valuable early time. And I've shown that in the map there I've shown that the voyage there the red dots each day. The blue ones are like blue ones being made aware there are storms, according to the ship, both in terms of above they're the blue line of the barometer readings. And orange, but the barometer readings there, the dips in them. And I've also put in a pretty bad to read it but from the actual logs whether there was evidence that this really was wasn't an aberration. There's a lot more quality control on it, but each one of those dips there with this, but it seems to suggest that the storms, we were able to attribute text from the the volumes which said that there was pretty rough and pretty bad weather conditions. So this gives you some very valuable information that's just one ship. And to conduct ship so we have the next slide. This is a settler ship. And again, train my bias. This is HMS Buffalo, which brought the first European settlers to South Australia my home state to Adelaide in 1836. And again, this has pressure in blue and temperature in orange there, and the trace of the voyage and you can see that they they have certainly around that's a lot of part of the voyage there Indian Ocean in the blue there they had quite a rough time there. Some stage towards is November, really December of 1836 before they arrived in South Australia so again just examples of the sort of things that you can get from these these voyages so the next slide please. And I put this one this is this is again a settler ship this is the Tory which went to New Zealand so we can't keep out keep on New Zealand friends out of all of this I'll get into trouble with them. But this ship was actually the readings from this ship were actually made by a German naturalist who was going out to New Zealand to do studies of the, you know, the environment and the natural world out there. I've got bifenberg if I thought that correct. But the interesting thing here is he had not just blue pressure, orange or red temperature, but in green sea temperature. It's splitting the unfortunately in the record we've got it in two pieces. I don't know what happened the middle bit seems to be missing, but at least we've got something. And then after in the second part of the block there you see, there's also in black, something called a temperature. I might go into all the details about it but it's a sort of barometer, which I think uses oil and all sorts of other strange things a bit of a monstrosity apparently, but it was to try and capture rapid drops in pressure with storms obviously. And so we may be able to use this as a pieziometer and barometers from what we can tell so far, don't always match up terribly well but this one looks like it's not too bad because when the barometer broke, you can see that maybe I said that the blue and the black lines aren't too bad. And so we may be able to use this pieziometer going forward to help us with the again as a pressure source if you like. So next, next slide please. And just to show you sort of ship tracks and things they're made in 5480 just pick up a few years, but the point to show here was that for the region in red showed around Cape Town and the region around Perth in red circles there. So we've got the member earlier that Cape Town and Perth pressure, we've got these ships that I just showed you convict settler whatever going around across the Indian Ocean like that. So one of the things we're hoping is that we'll be able to do a study of the least the pressure data, the land data at Cape Town and at Perth, against the ships as they are the stop the stop the Cape Town or Perth, or usually went past. So we're hoping that this might be able to help us to adjust things and see whether it all makes sense or whether there's something other things that we need to take into account to improve the record. So, move on to the next slide please. And just to mention, Captain Cook's 250, there's a few years ago now. And beyond that, we've been looking at pushing things to the limit, looking at some of the early voyages of explorers including Cook and green are the ones that we've been digitised and yellow ones we haven't got much data or any data out of. Most of them have some sort of air temperature, like the conduct ships or and some though fortunately do have barometer pressures in there. So if we look at the next slide, we can just see some examples. So the top left is Cook's three voyages they're shown in blue, red and green. You have the next to that across to the right have Vancouver in 1791 to 1793 he has voyage there. And again, valuable tracks, they're going where, you know, hopefully we can get data and we have got data from that. Below that on the bottom left, La Peruse for he was lost. The story there was that I got to the fledgling colony of New South Wales in 1788 was when the first fleet went out to Australia. They were alive there sometime after the first leader just had landed and they left, I don't know it's copies or I think it was copies of their logs with them. And then when they just went off they disappeared in recent decades as the actual ship been found. But otherwise we would not have had this data, if they hadn't left a copy with the British ship in Port Jackson at that time. So the Malaspina's voyage, 1789, 1794, and again data we've got from these voyages. So I think I've covered two English, one French, one Spanish voyage so hopefully that covers a few wider ranging things. So next slide please. The next estimate is that worldwide there's something like 10 million logs as a ship logs, there's also the land data as well and related items that have yet to be discovered so there's a massive effort that we're going to have to put in an ongoing effort to find and recover this and we've found stuff in all sorts of strange places, in Scandinavia for the ships, the old wind jammers going out with the grain and stuff to Australia in the late 1830 19th century places we didn't think that these things would exist. So a lot to do by go to the next slide. This is something we've just recently discovered a few years ago now I was pestering one of my Portuguese colleagues because she mentioned about stuff that they'd had, which was supposedly lost in a fire in 1978. And after a bit of effort they discovered that in her university, Lisbon there, but in the attic. And as you can see here in the slide all this material which we thought lost was actually saved or at least a portion of it made like a portion of it was saved. So it's all bound up it's seen smoke damage water damage you name it. And we really need to get at that so the next slide. Thanks. And that gives you a better idea of what's there. I kind of got some money for my Portuguese colleague to for her to do this work. But it's, it's probably the biggest curation effort in terms of actually getting to the data that alone, saving it after you digitize the scandal and whatever that we've faced. And she's going to have to get professional people in to be able to open these parcels successfully carefully to be able to get the maximum of information down without destroying the data. So the next slide quickly. And this is another source in Lisbon to hoping is that their archives and marine archives over there, all sorts of types of ships logbooks and lighthouse tenders and all sorts of things we need to get at and so we're slowly focusing on that. So I'm almost to the end now I've got two slides to go. The next one please. So we have to operate like these guys pirates of the Caribbean. We really have to be sort of inventive look for not only sources of data, et cetera, but also the funding, the personnel to do this it's not something where you can say okay we've got some money latch onto that. And that's it for you know as long as we can, because it changes very, very rapidly and it's something where it takes quite a lot of effort to discover it. And finally I'd like to last slide please I'd like to dedicate this talk to my friend and colleague Dr Kevin Wood who unfortunately passed away back in February. Kevin was our ACA Arctic lead. And he was based at the Pacific Marine Environment Lab PML at NOAA in the US in Seattle and also linked to the University of Washington I think. He was a fantastic guy and had battled for at least a decade or more with the lung cancer. And unfortunately it caught up with him and very sadly lost in February so I'll end on a bit of a down note but I hope that what I presented will give you a feeling for the sort of things that we do and need to do to make ACA work and be successful. So thank you very much. Thank you very much Rob, fascinating combination of historical and climate science activities there so thank you very much for that really interesting. We've got time for a few questions. So if anyone has any please do post more in the Q&A I've got a few that have come in during the talk that I'll start with if that's all right Rob. The first one is that you mentioned that you've got a wide range of data sources from measurements, historical data, citizen science inputs. How do you how do you kind of balance the relative value and worth of each of those data sets when you bring them together and manage the very level levels of confidence in the respective sources and actually related to that second question was just how do you make judgments about the quality of data when you're Well we're trying to quality control as most people do well everybody using data needs to do initially so you know to very basic things like checking nearby stations but also various algorithms to check that the the data looks reasonable. I mean even even the most basic first thing you can sometimes tell straight away if there's something wrong there. So you need to do all those techniques from the most basic right through to sophisticated initially to see whether the data holds up. Now the other thing that's very useful in terms of using the data in the next step with the reanalysis or whether reconstruction is because they have another level of check before they assimilate or absorb these data into the reanalysis so they will reject data for all sorts of reasons. So you've got several levels of checking I guess I'm saying from what we do for the data goes international repositories to holding quality and quality of data, but also people are using the data. And so the reanalysis do a whole lot more. And the other thing at the other end of their output is that when they output their renounce I didn't really show any reanalysis much alluded to et cetera, but when they actually produce fields of pressure or winds or temperature or whatever reconstructed over time. They're also able to, because they've got these, in this case now 80 realizations that they can look at the spread, and they can see whether the observations of any parameter in any place in time and space converge so you're rating realizations. How well do they converge and put criteria etc. So again that can highlight if there's a problem with the data, it may not be the data quality maybe just something else but again we'll pick up these various things so we have this sort of beginning middle, sort of end quite but checks on the data as a consequence of it's it's it's about making available and usage. A second question, actually again sort of to two related questions really. When you look at the fact that acres operated in various regions around the world. How do you go about implementing common data standards so that you've got into operability of the outputs across those regions and a sort of related questions are the challenges different in the different regions. Okay, so it's really between regions because it's all coming in to a central source or sources is what I just said in the previous answer applies to that. It's all going to be treated equally. So, you know, you're hoping that your colleagues in various parts of the world and these various acre regions or chapters are doing a good the proper job when they're pulling this together digitizing on stuff but it's all going to be looked at as a mass by, the whole thing that as I've said before by the actual repositories, their quality control equity control on it by the reanalysis quality controls, etc. And what was the other second question sorry I'm just trying to remember. It's just whether whether the charges kind of differ between different regions. They can be that can be very different yeah. We've tended to sort of develop regions. We have somebody who's taken up the gauntlet you need a champion or somebody who's prepared or is it a position to be able to do it. And this is why it's important to work carefully with them. And yes, sometimes there are more challenges. It can vary from all sorts of things. Like I've sort of been saying there. Now, Argentine colleagues found a lot of data online on one of these sites scans of the data. They could get them most of them, but then there's a lot of them because of the nature of the site, we said oh unless you're based in the US you can't access it so they have to go and talk to them about it I mean even on that sort of level. And it just depends. I mean as I said my colleague Stefan Graven South Africa is out talking now as I speak probably to farmers trying to recover you know go and speak to the one to one to recover data so it does vary in that sort of way. But also in terms of the where the sources of the data and I think you saw there there's a whole plethora of different parts of the areas where the data could be held in different parts of colonial administrations etc. There are varying challenges like that we need to take into account to it. Yeah. Great. Thank you. Just looking through to the other questions. So I mean, this is clearly a large international initiative. How do you go about coordinating funding sources and prioritization across acres a whole isn't as a global activity. Get what we can when we can and where we can. And it's very is quite a bit over the course of the 40 15 years that's existed. We've been able to get it becoming this become integral part of the Met Office where I'm based. You know over that is evolved over that time because originally this was actually funded by three years of money from the Queensland State Government Australia for me based at the Met Office to do this acre project at that stage and it sort of grew from that. So we have to be, you know, pretty quick in our approaches and nimble. I think it's the better word in terms of actually finding data.  I don't think there's a funding system the whole thing like I don't think there's a funding store pot of gold somewhere on high, which you can tap into that's going to be there for five 10 years or more. I just not there, you have to be able to do it this way I think because I don't think if you go too much straight and straight narrow on the findings, it just won't hold up. So we have to be very careful what we do and also very nimble as I said in terms of where the sources might be both not terms of funding but in personnel as well. So one final question from from the Q&A. So this is it's fascinating to learn about how all these old logs are imaged and called data. Is it simply hard graph that enables you to get the data out or can you use AI techniques to cover some of the data at all. So what sort of approaches do you use to extract the data. Well, I guess up into a more recent was probably still is hard graph is an element of high graph with it. I think that's that's what we've found. You should going from cottage industries to to sort of industrial scale where you might have a block of stuff you send out to someone to digitize specialists to digitize. But you know you've got to be again to be fairly nimble about all of this. And it's only recently that AI colleagues of ours of acre to acre have begun to look at things like AI and we have fingers crossed that that will eventually come to fruition and we'll be able to actually, we'll be able to do that at the whole sort of, you know, thing that the data sets, the material that we need to get, you know, it really would be a revolutionize what we do. In some ways citizen science has been slight revelation, you know, to get more people to do it, and if nothing basically, but it's a benefit. But yeah, it's coming. But AI and even optical character recognition is still not quite there. We have tried it. If you fiddle around with it, you can sometimes get to it but something where you can just take whatever a journal logbook and put it through something and, well, it takes the whole lot is still to come. I think that that's probably we're coming close to the end of our time now so thank you very much again Rob for that very fascinating presentation and discussion. Just serve as well with the session was recorded it will be made available on the, on the website but also on the YouTube channel so just a reminder, once again to subscribe to that channel if you're not already doing so. This webinar in the series will be on Friday the 8th of April at 11, and that will be presented by Malcolm kitchen, looking at opportunistic data for weather forecasting so please make a note of that. Book your place on the website and get signed up to come to that one. And with that, I think that that's it for this morning so thank you very much again all for making time to attend thank you again Rob for, for your presentation and discussion there, and we'll close the session there so enjoy the day. Thanks so. Thanks, I don't know. Thank you very much.


Unify, 5.12.35 is out and ready. It's just been out for a couple of days. I loaded on our server and based on forum posts, because we didn't have any problems with it, but I'm not saying that doesn't mean there's not problems. People had some update problems. People said it was using more CPU. I know they have like, I turned it on as well. The Wi-Fi AI system I talked about with my more in-depth video about all the new features that came with the 5.12 update. But this is just an incremental update to address a couple minor issues. One, the problems people had upgrading. Now, my upgrade process is pretty straightforward. One, we have auto backup turned on, so I'm not too worried about backups. But I still back the system up, download the file, so it's not on the system itself, just in case.  I don't do it through the repositories. I like to mainly load and purposefully do this. Then I update all the firmware. If there is any firmware updates on different devices that are attached to the controller, and away we go. Now, we manage this for all of our customers and things like that, so we're careful about how we do it. It's really a real pain if all this was broken. So that's why we have all the backups, the snapshots, and the methodology by which to roll back. Now, the first thing that I'll note that I tweeted out was thanks for asking. And that's because this is the big feature change with the 5.12.35. Security and analytics. Send diagnostics and usage data to Ubiquiti, help Ubiquiti improve its products and services by automatically sending diagnostics and usage data. Send or don't send. This is the first prompt you get after the upgrade. I've already clicked it, so I can't show you again, but I screenshotted it, because I figured once it asks you, a login is not gonna ask again if you turn this on or off. I believe wholly that companies need data in order to understand how you use their products and to improve the services of those products. If they understand every environment that you're in or have a lot of data from the different environments, more than the labs that they do their own testing in, they get better understanding, oh, this is a problem, or this is a feature we should focus on. This is how you help steer your engineering team. What we do know is when they didn't ask us, a lot of people got mad, including myself. You know, I did a video and, you know, not that I'm really ranty-ravy, but I was like, you gotta ask first. That's just a general politeness. Even if it's in your terms and conditions that we know no one, except for someone, that one person has got a lot of time in their hands and understands all the legal jargon in there has taken the time to read, that yes, it's probably in there, so undoubtedly it's legal to do, because there's, you know, I'm just feeling that Ubiquiti probably has a lawyer or two that says, oh yeah, you can do that. And there's probably some product guy going, we need the data and there's some engineer going, you should probably ask the users first and, well, we see who won Ubiquiti finally decided to add an update to do this. Matter of fact, it's the only major version change it looks like, besides the usual generic wording of some performance, improved performance, fixed ability and control interface was add analytics opt-in modal, which is displayed post upgrade and add a toggle on and off for analytics. So even if you say yes or no, you can change your mind later about it. And I don't like to set up a problem giving Unify the data. I just wish you would have asked first because this is important, but for those of you that don't want to, now it's an easy option versus actually sync holding it. So our controller is running in 5.12.235. I'll go over here to devices and I've updated the firmware on each of the devices. So everything's running all the latest firmware and it seems to work perfectly fine. I didn't notice anything new. Go over to my video, which I'll link below the 5.12 video where I did talk about this as a major update with a lot of new features. Now interesting in the Serata is a feature to fix, restore and UDM when default site does not have a gateway present. Here's the UDM. That's why it's sitting next to me. So I was kind of curious and I'm under the updates. Let's go ahead and check for update. It is November 25th, 2019, six days after the release. I believe this is six days ago. Yep, six days ago is when they published it. This dream machine that's been sitting here doesn't have an update. So I thought it was odd that they had it in the Arata that there's an update for the dream machine but the dream machine doesn't seem to see an update. So maybe it's just a stage rollout and maybe it'll cue, but I did try forcing the update. So I thought that was interesting that the unified dream machine still is on the 5.12.25 version. So it works fine. It didn't have any problems with it. And I have a few videos on the dream machine itself in this product, which has some mixed, some people hate it, some people love it. It's got its use case. Watch, I'll leave a link to that video as well. But there's not much else to the update other than thank you for the privacy notice. I'm fine with sending data when you ask me on sites that I don't have a problem doing that with. Obviously some of my clients that work, especially certain government ones who want no data leaving, they can say no and they say no data leaving or some home users that are convinced everyone's spying on them. Hi, I've seen a few of you message me interesting messages. Say no, you can say no now and you don't have to block it or anything like that. They've got an option for you to click the no button and not send data. So there's that. That's all I got for this update. There's like I said, not a lot of new features. It's more like some tuning and enhancement, the usual bug fixes and the privacy notice. So I'm gonna say thanks for that. I like the fact that they added that as a feature because they should have done that from the beginning. So hopefully any other companies could learn from this the outrage that it seemed to spark when you, even though it's legal that you don't ask, ask first, that's all. Ask us and a lot of people like myself. I don't mind sending you some data. Thanks. And thank you for making it to the end of the video. If you liked this video, please give it a thumbs up. If you'd like to see more content from the channel, hit the subscribe button and hit the bell icon if you'd like YouTube to notify you when new videos come out. If you'd like to hire us, head over to laurancesystems.com, fill out our contact page and let us know what we can help you with and what projects you'd like us to work together on. If you wanna carry on the discussion, head over to forums.laurancesystems.com where we can carry on the discussion about this video, other videos or other tech topics in general, even suggestions for new videos that are accepted right there on our forums, which are free. Also, if you'd like to help the channel in other ways, head over to our affiliate page. We have a lot of great tech offers for you. And once again, thanks for watching and see you next time.


Well, I think we will just get started. Yeah. Yeah. Welcome to my talk on building FlexJ applications, FlexJS applications with Maven. Well, if you sort of looked through the history of talks I did, you will probably see sort of this name quite often. But the strange thing is, every time I hold the talk, it was something completely different because it was such a moving target. Last year, I had this talk and I was building with FlexMojo's. Well, I was going to talk about that. That was sort of a just in situation. Things stopped working the day before I held the talk. But today we're talking about something that's working. Hopefully. Yeah, well, yeah, they got it. A little about me. Well, I really feel sort of strange introducing myself. I think you all know me. But well, my name is Christopher Dutz. I'm a senior IT consultant and work for a company called Cotentric. I get one day per week, usually, to work on open source stuff.  I did the last few years, so I was able to actually do quite a lot more work on open source. As my time there, I'm an Apache member. I'm part of the Flex PMC and committed there. I had been the FlexMojo's lead developer. Well, I still am, but I'm not very active there. Because due to recent changes in the Maven project, it started getting harder and harder to support that. So that's sort of a dead end for me. I'm a total open source enthusiast. So all my free time sort of goes into open source projects. And they're all my Twitter handle, if you want to see what I'm up to. So what am I going to talk about? Well, first of all, why Maven? After that, I'll just fly through a five minute Maven introduction, sort of just get the interesting parts and point out what they are. A teeny weeny little introduction into the Maven Flex.js build life cycle. So who here knows Maven? OK, so everyone? Yeah, well, maybe I'll just do it for the recording. Then I'm going to show you how easy it is to get started with building a Flex.js application with Maven using one of our archetypes. We've recently started creating quite a lot of little archetypes for different scenarios. So I'll just show you how easy it is. And then we'll have a little deep dive into the POM XML, the configuration, to show you how you achieve different things. Yeah, after that's done, well, I'm going to talk a little about the current development, what I'm currently working on, and what is to come. And hopefully, you have some questions that I'll answer then. But you can always interrupt me if there is something you don't understand. So why Maven? Well, Maven is a well-established standard. It works everywhere and sort of works at every customer I came across. It has a great IDE support, well, except Eclipse, that sort of has issues. It has an even better CI server support. So running unit tests on Jenkins is really easy. And it has a well-established standard for accessing dependencies. In the last few years, I've noticed that with upcoming of SBT or NPM, a lot of problems at my customers were related to, well, they have their closed environments, and it's problematic to get dependencies using these other not so established build tools. But Maven worked in every place. So I really like that. The super-duper-mini five-minute Maven introduction, I think it might even be less than five minutes. Well, the main thing is, in Maven, you describe your build in one file, the POM XML. It's the project object model. You describe how things are built, what dependencies you need, and, well, as I said, everything you need to build the project goes into that file. Maven is built up around the concept of inversion of control. So if you're used to and, you usually say tell and do this, then do that. And before you can do this, make sure you have done something else. And you describe every step of the way. With Maven, that's a different approach. Maven sort of says, yeah, well, I'm in phase X. What do I have to do? I'm in phase Y. What do I have to do? And it has a very fixed lifecycle. The main concept is that the default use case should work with almost no configuration at all. So an ideal approach would be for a FlexJS application that I just specify the type, SWIC, or SWIF, and off I go. Configuration can be used to sort of change the defaults and adjust it to your needs. Well, same as if you're building a JAR file, well, you will probably have use cases where you have to fine-tune the build. Same applies here. But Maven allows to do that really easily. One thing that's really great is its dependency management. I remember we had a lot of issues with the ant build with dependencies that sort of had to be downloaded and sort of verifying checksums, getting transitive dependencies, servers that sort of move, have different URLs, or there were a lot of issues in getting stuff. With Maven, it's really easy. Well, as long as you sort of use well-established stuff and, well, we are using almost just standard stuff. So I think that's a really, really great benefit of Maven. So I think a lot of questions on the mailing list I've come across and answered in the past were sort of related to, where does Maven put stuff to and where does Maven get stuff from? Well, let's say this is sort of the default setup. You can see at the bottom you have the project. It sort of consumes, let's say, artifacts and it produces an artifact. Maven takes care of sort of storing that in the local repository. That's just a directory on your hard drive somewhere. Or it gets stuff that's missing from a place called Maven Central. That's sort of from a Maven point of view that's home. If it doesn't find anything, it asks home, do you have it? If it has that artifact, it downloads it, stores it in the local repository, and passes that on to the project. So that's the default case. In case of FlexJS, our ecosystem is a little more complex. So we had to solve quite some problems and that's sort of how it looks for FlexJS. So everyone who is currently working on the development versions or working on snapshots, you need to tell Maven about the Apache snapshot repository. This is usually done. Anyone who had checked out our source code before, you'll find a file called settings-template.xml. So that's a little example file that you can use to tell Maven about the Apache Maven repository. And as soon as you specify that, a lot of problems go away. But not all. Well, that's a good question and I'm just going to come to that right away because not everything we need is available in a Maven repository. As FlexJS is able to compile JavaScript, well, we're safe on that side, but also for Flash and Air, we have dependencies to stuff Adobe provides us with, stuff in the Air SDK or the player global resources. They aren't available as Maven artifacts. So times prior to Apache Flex, the guy who maintained FlexMojos, he sort of had to deal with Adobe to manually convert an Air or a Flash, Flex SDK, into Maven artifacts and publish that. But we didn't get that permit, so we had to find a different way. And we're using Maven extension. It's sort of a really low level extension of Maven itself that intercepts requests sort of like an adapter sitting between Maven and Maven Central. So we check if Maven tries to resolve an Adobe artifact. And if it doesn't work, it intervenes and asks the user if he accepts a license and if he does, it automatically downloads from Adobe's web servers, unpacks that in the temporary directory, and locally does this conversion automatically. And that is the reason why we have to put the repository in the Settings XML because the Mavenizer sort of has to be found before Maven even starts parsing the POM. So without this, Maven would just say, yeah, well, I can't find it and just dies. With a Mavenizer, it does find it. As soon as we release the Mavenizer, or the, well, let's call it, the official name is the Flex SDK converter, I think. As soon as we release that, a lot of that hassle goes away because then it will be found in Maven Central and we no longer have a need for that. But I still have to put a lot of work into that, especially in handling DMG files. But we're on a good way. So that was the five-minute introduction. I hope it was sort of five-minute-ish. Anyone who wants a more detailed one, we did a recording last year in Vancouver and thanks to Justin, who sort of spent 100 hours in cutting all my irms and urrs out of it. It's even relatively short. I think the talk was about three hours and the final version is two hours and 50 minutes. So that was a lot of irms and urrs in there. So feel free to have a look at that. We put it online just to educate the project to get a little more comfortable with Maven. So assuming I said that Maven has a fixed life cycle, it does look rather complex and anyone who had a look at the video will probably recognize the picture. I doubt. I have no idea, eventually. I don't know. Well, as I said, every project has a fixed life cycle. So it does look rather bad if you look at it that way. Can you read it? Yeah, so you can see that. If I, for example, say I'd like to run test, I know that it's gonna go through validate, initialize, generate sources, processors, and all these steps up to test, including test. But it doesn't mean these are offers Maven provides. So it sort of starts, okay, I'm in the validate phase. Does anybody have anything to do now? No, okay, then how about initialize? Are there any things we have to do initialize? And exactly what has to be done in which phase is defined by the packaging. So I think you might have seen one of these POM files. We're gonna look at one in a few minutes. It has a packaging type. And if you set that to SWIC or SWIF, Maven automatically knows what to do in which of these phases. I summed them up a little, and I think this isn't even gonna fit on the screen, but I think you're gonna get quite a good idea of what's gonna happen. For example, for a SWIC, a flex library, we only operate, for example, in the generate sources. For those of you familiar with FlexJS and these, we call them type defs. And when creating the slides, I found out that I should eventually change the name of that goal to generate type defs. It's a part of our build in which we parse JavaScript files and from the JS doc annotations, we create AS doc files that will be used to tell the IDE about types of non-flex libraries. So we can use normal JavaScript libraries, put them into our project. If they are equipped with these JS doc annotations, this phase will produce the action script code that will be used as interfaces. Then we're using the default Maven resources plugin to simply copy static resources. In the compiler, if you're using the ant version, we did have problems in the past that if you had static resources that were not JPG, but JPEG, things didn't get copied. That was because the compiler handled things manually. In the Maven world, we simply rely on the Maven resources plugin and whatever we put in a resource directory, that's copied to the output. Then come the fun parts, the compilation. So we have the compile AS thing that deals with compiling the flash version. We have the part that deals with compiling the JavaScript version, and we have a part that compiles the type diffs. They have to be sort of compiled slightly different, and I think I might be able to reduce these to JS and AS plug-ins into one after the last changes. But right now, it's sort of three executions, but Maven sort of decides on, well, there's no JavaScript in here, so I haven't generated anything, so I'm not gonna compile the type diffs. Yeah, we already got, I got everything set up to be able to start compiling, generating, and running unit tests, but I haven't filled these plug-ins with life yet because I'm still waiting on getting some time to finish FlexUnit to compile. When I look, well, this is the life cycle for a library, so if I say type SWIC, that's what's gonna happen. If I put SWIFN there, that's when we wanna build an application that we can actually run. So life cycle looks a little different there. You can see there is no extern generation because type diffs are always libraries, never applications. So you can see in that case, in the compile phase, we're running compile app. I think I could have left away the test things, but in the end, for example, the package phase is quite interesting in this case because if we compile for Flash, the output is one file, but if we compile for JavaScript, we get a directory full of multiple files and Maven doesn't like that. Maven only likes one single file to be deployed because it sort of uploads that to remote servers and it only uploads one file and no directories, and that's why in the package.js plugin, we sort of pack up everything that the compiler produced and create a bar file from that. That file is then sort of uploaded or locally deployed and it gives us the chance to use who of you has built a web application with Maven? So, oh cool. So let me explain a little. So assuming you're building a server side web application and you want to bundle a Flex.js front end with that, you can easily now use the overlay mechanism to simply take the content of one of those Flex.js vars and simply unpack it in the output of your application.  You get a var file that has the Flex.js application included. Maybe it's better to have everything in the same project because if you make a change to the back end, a front end as well, but if you have separate projects, you have to release the front end at first or put it in the server when you want to change the back end API. Yeah, well, the thing is, I never have my code in my web application module. I usually have my code and my API in separate modules and then I sort of have the var plugin or var project is simply a wrapper that sort of packs everything together. So yes, I do have the Flex.js application and the server and the API in one multimodule build, but not inside the same module because I usually, I have my model and that's built and then I have my action script model generated from the Java model and sort of then that's built and then everything's packed together. So yeah, I think you would get into real big trouble if you sort of started having one Maven project with Flex and Java and that. So I think that would be a pack with the devil probably. Yeah, okay. So I said, are there any questions to the general way Maven builds? So okay, yeah. Yeah, well, usually you're not allowed to deploy anything at Maven Central, but it's sort of, there are other Maven repositories hosted by other people. For example, the company Sonatype who sort of created the software Maven Central runs on, they have their own repositories. It's the Sonatype OSS repository or so. So you could sign up there and so you have to do a little paperwork, but as soon as you get that done, you can release stuff to their repository and that gets synced to Maven Central. The other way is we have our own Nexus installation at the Apache Software Foundation. So that's the repository you have to tell Maven about to find the Mavenizer. So that's where that is. And as soon as we release something, it sort of disappears from the snapshot repository and goes to the official Apache release repository and that is again, synced with Maven Central. So when doing a Maven release, I just did a Blaze.js release a few weeks ago. All I have to do is sort of close repository, except and yeah, I think a few minutes after that, things pop up at the Maven Central. Yeah, okay. So one thing I put most of my time into is making it easy for people to get started in developing with FlexJS or easy to contribute to FlexJS. And after cleaning up the build greatly by adding the Maven build, we started providing little so-called archetypes. Maven has this archetype mechanism that allows projects to sort of create little templates for different use cases. And for example, we now have five archetypes. Well, one is a simple application archetype. It's an archetype that produces a Hello World application that you can compile to Flash or JavaScript. Then we have a pure JS archetype that might be interesting for people that want to get started with, that only want to target the browser and don't care about Flash, or they want to use some libraries that will not be available to Flash. So the pure JS archetype will help you get set up there. On the other side, we have the same with a Swift archetype. So that is a project that just builds Flash. That could be interesting if you're planning on building a mobile application that sort of uses some features of your mobile phone or so, you will never compile that to JavaScript. So that's a good starting point for pure Flash development. The last two, a simple library archetype. So if you want to sort, you don't want to build everything into one big application, but you want to apply some separation of concerns and split up your project into multiple parts, the simple library archetype will help you set up a simple library. Last, not least, we have the type def archetype. I think this is a really interesting thing because with this you can set up, assuming you found this fascinating JavaScript library and you would love to write a Flex application that uses that. So by using the simple type def archetype, you'll get a project which you can sort of drop in some JavaScript and it will produce a Flex library that you can start writing code for this fascinating new library you found. Okay, so don't want to be just talking, okay? It's not even doing some line breaks. So now we're going to have a little demo and I'll just show you how fast and easy you can get your first Flex.js application running with Maven. There was a trick, I think, because that's full screen, isn't it? Can you see that? There, where's the full screen mode? I hate that. So let's make it a little easier. I already typed that. So what happens here is, it's not recorded if I go there. What happens here is we call a Maven plugin called the archetype plugin to generate a project. If we just left it there, it would sort of look in Maven Central and look at all the archetypes there are. If you started using archetypes about 10 years ago, that was cool, but right now, I think there are several thousand archetypes you sort of would have to scroll through. So what I'm doing here is I'm providing the group ID, the artifact ID and the version of the archetype I want to use. It looks a little lengthy, but there is no real magic to it. Any questions? You sort of, or it's just too hard to read. Oh well. Okay, so off we go. And fingers crossed. Okay, so it's asking me for a group ID I want to give the thing. So I'll just call it Org Apache Flex Demo. Give it a name. It already suggests a version, a package name. Asks me if I mistyped anything and it's generated. So you can see there's a POM and a source directory. So if we want to build it, you can see the, did you saw the ASCII Art logo? So that's the little thing I built into the mavenizer to that you can see that it's actually working because we did have problems in the past that people said, yeah, well, I did it and it still doesn't work. If you see that, you're safe. I hope it says build successful. That's good, but it doesn't have to mean it works. So now I'll just go into that directory. So now you can see in the target directory, we have JavaScript bin debug and there's the index HTML. And as soon as I open this, I really hope I'll see this hello world. That's awesome. It's the coolest hello world in the world. But we could also see that there was also a Swift. Here it had the, on this side it said hello, hello world. It's a shy hello world. Yeah, well, so you can see it was really, really easy to get started. Well, it's getting a little, it will probably get a little more complicated if you wanna do more than just this little hello world. Yeah, I'll just open that here and push it over and use the cool presentation mode. Ah, I can see it here, okay. Never quite used that. So there it is. Where's the palm there? Okay, so as you can see up here. There were the coordinates, the archetype asked me. So the group ID, artifact ID and version, the Swift packaging is coming from the template. Also, I'm defining a variable there called compiler.debug. I use that to sort of set the compiler to produce debug versions and optimized versions. The optimized version still builds the debug version, but it sort of processes the debug version to become a final version that does all this minifying and stripping away of the code. The important parts here are this extensions tag because if you leave that away, Maven will complain that it doesn't know what to do with the Swift packaging on top. So by defining the flex JS Maven plugin and telling Maven that this is an extension, you will be able to build flex JS applications. I did create the plugin that it's completely separated from the compiler itself. So it should be possible to use the flex JS Maven plugin with the original flex compiler. It's completely separate. So you have to provide the compiler you want to use. We were also thinking of moving the Maven plugin into a separate project so we could release them separately. So that's just something you have to keep in mind. You have to provide a reference to the compiler. Here all we have to do is tell the compiler what's my main class and what type of output do we want. So in this case we're creating the Swift and the JavaScript version. Our code does depend on some other libraries and these are defined down here. And here comes one specialty. Well, we need core where we got some of the core functionality. So we got a normal Swift dependency on a core but for example when compiling the flash version we need a reference to player global or error global. That's sort of the core library for everything built with flash. And the JavaScript version in contrast needs the other two libraries defined down there. So if you just build a flash application you can leave the lower dependencies away. If you're just building a JavaScript one you can omit the error global reference. Yeah? Yeah, well, I, oh, I think I have to adjust my archetype because there should be a debug that references the variable. So if I tell Maven to use the release profile that it sets this variable to false. A good point. So any questions to that? Oh, yeah. Yeah, just let me, so that's not the right one. Is it now? It says it's the FlexJS version. Is it? I'm just gonna close that. It must have sort of magically disappeared. It's still telling me it's there but I can't see it. Where's it behind everything? I'll show you after. Yeah, it's quite easy. It's sort of these archetypes are sort of simple Maven modules in which everything you need is sort of put into the resources of source main resources of the archetype module. But inside the archetype you replace things you want dynamically updated with some escaped values. It's sort of a templating thing. It's quite easy to understand. No, not at all. It's just text editor. So let me get back. I hope I'll find my way back to my presentation. Oh, that's looking good. Okay, so. Okay, I already did the dive into the palm. So, not all is good right now. Not all dependencies are available as Maven artifacts. Well, if we go down the JavaScript path, it's great because we have the opportunity to work on that. But on the flash side, Adobe will never release their stuff in Maven Central. So we will always have this problem of providing these resources. The Mavenizer, I'm currently working on the last pieces I need to release that. I didn't want to release it before being able to process content in DMG files. I know on the mailing list there were some discussions about using system calls to execute that. But I'm no big friend of that because right now the Maven converter is able to even produce Mac libraries on a Windows machine. So I wouldn't want to give up on that. And these executions would simply miserably fail on a Windows machine. So I'm currently implementing the DMG decompression code. I'll probably put that to Apache Commons. Unfortunately, the Apache Common guy just left. Yeah, so that's what I'm currently working on. And as soon as the Mavenizer is released, we are getting rid of quite a lot of problems. Right now we are using simple compile scopes in Flex. So we don't have big problems at the moment, but everyone who worked with the old Flex SDK, you know, we had scopes like RSLs or the signed RSLs. Or yeah, we had different scopes that Java just doesn't know about. And with Flex Mojos, we sort of worked around that because there was a bug in Maven that sort of, as soon as there was a scope, it didn't know. It sort of defaulted to compile. That was cool because we could do whatever we wanted this way, but they fixed that bug. And now, transitive dependencies of non-compiled scopes aren't resolved anymore. So if I had a library that, if I had a library A that requires B and I would include it as a normal SWIC, that would be okay. But if I sort of said, yeah, well, that should be an RSL, then we wouldn't get B. So we would have to start and try figuring out, sort of declaring dependencies multiple times. I'm no big friend of that, but the good thing is, I've been talking quite intensively with the Maven guys, and they just recently got a part of code we needed, donated from the Eclipse Foundation. I don't know if you followed that discussion, the Ether project, the Eclipse Ether project is now part of Maven. And now we have control over the code we need to be finally able to provide an extensible mechanism for providing non-default Java scopes. So I'm currently waiting on these extension points to be established, and as soon as that's gonna happen, I'll be doing some really deep Maven extension stuff. So we can finally use all our good stuff with Maven without any problems. Another thing that's currently bugging me quite a lot is a few months ago, SourceForge updated their SSL encryption. And that's sort of, people from the US will probably not have noticed that, but everyone outside will, because Java simply isn't able to support that deep level of encryption. And this level of encryption is sort of, I think there are some US export restrictions that sort of prevent that from being shipped with a GDK. There seems to be a way to manually install Java cryptography extension to make Java download that, but I haven't seen that work reliably. So it sometimes works and sometimes doesn't. Yes, Justin? Yeah, okay. Yeah, well, it's one thing. I think it might probably be the easiest way that I simply re-implement the libraries we needed from there, because it's simply the font kit stuff to do the font encoding that we are still using from, I think it's still version one and I think it hasn't changed for, feels like 10 years or so. So as soon as I re-implement that library, those problems go way too. But I have to implement that and I'm not looking forward to doing font encoding stuff, but, no, look at that. But I think we need a special encoding. It's not the decoding of fonts. I'm worried about there are cool libraries for that, but I have to encode stuff in a way the Flash player knows about it. And I would be surprised if Adobe chose a format that is standardized and, yeah, I don't know. Well, one thing that I would like to finish really soon is simplifying the dependencies. One thing you didn't see, but I can show you later on, that we are building two versions of libraries, one that was compiled for JavaScript and one that was compiled for Flash. So we do need to reference both libraries if we want to be able to build both types and I think that's just too complicated for most users and with the changes in the dual branch, it should be the first step on a way to produce swigs that contain, has any one of you had a look into a swig? So inside a swig there is a catalog XML and a swith file that contains the bytecode for the Flash version. So what I'm proposing is that we sort of have a catalog JS XML file in there and the corresponding swith file, the Flash site would simply treat that as binary garbage in the file and it wouldn't mess up anything there and we could make our compiler sort of look into that catalog file. So we wouldn't have to do this distinction. We would just have I need library X and version Z and we wouldn't have to do define multiple dependencies. Now it's still producing two files and you still need to, if you have a look at the examples that it usually says, well, you depend on core and core internally has, well, I depend on something else and something else JS. So this morning that was the first thing I checked when I woke up this morning because sort of was lying in bed was awake and thought I didn't see any JavaScript dependencies in my archetype.  So I just did check and yeah, okay, it's just one level beneath. So an end user doesn't explicitly see it but we do require two versions. Okay, you do probably. Okay, yeah. Well, talked about the past and the current situation. What is to come? Well, the top thing on my list is the mavenizer. I don't know if anybody still remembers that but that code was the thing that got me involved with the Flex project. I donated it shortly after going to ApacheCon in Zinsheim and it's still in the 1.0 snapshot. So I should probably finally finish it, release it, ship it. Next thing on my list is FlexJS unit support. The old FlexMojos did some really nice job sort of scanning through the project like the JUnit integration does. It scans for test cases and automatically creates a runnable test suite and runs that and sort of instantly starts a listener that the browser then connects to and passes back information. So you can get a full unit test coverage reports that maven understands right outside your maven build. So that's one thing I'm gonna be working on. Another thing I started and sort of had to delay just as a lack of time is AS stock generation. Currently the project is focusing on creating a flex or an AS stock viewer that's created in FlexJS. But I think it would be good that we had a classical AS stock generation in maven that we are able to produce static HTML documentation pages. So IDEs and Google and everything that is used to handling HTML files for documentation will be able to provide direct documentation for FlexJS. Yeah, as I said, as soon as the maven guys fire out their extension points, I'm gonna definitely do the extension mechanism for dependencies. And if I still have any life left in me, I'll probably re-implement the Adobe FontKit libraries. What? Oh yeah, forget it. So yeah, I'm right at the end, 51 minutes, cool. So any questions? Has anybody? I was wondering, one of the things keeping me from, I'm not so sure how well it integrates with the instance. I don't remember I had this workflow in my introduction showing how I change a framework class and I can actually use it in the test application. Suppose I wanted to use maven on the framework. Would that be a problem? I mean, I know mixing and in maven doesn't work very well. Would that be a problem with the IDEs? I have no real idea because I was working on fixing IntelliJ's integration, but I didn't get that good support from the JetBrains guys. I think it should be possible because it isn't that difficult to extend IntelliJ. Justin, do you have anything to- Yeah, I tried that. Yeah, so that's the way I usually do it. I edit in IntelliJ and then I just hit the button and a few seconds after that, it's finished. Especially you don't have to rebuild the whole application every time you change something. So it is enough that if you work on HTML, for example, or a core that you just build that module, that's a few seconds and then you build your application. So yeah, that's one thing. In Seville, there were some guys from the Maven project sitting here and you could sort of really see them. He said clean install, oh, damn it. Yeah, well, in the Java world, it's usually not treated as good or best practice to do a clean install, but here we're producing a lot of different files and especially the state the compiler is currently in, I wouldn't trust it on working on things like incremental builds or recompiling stuff. So I would suggest to stick to the clean install for now. No, no. Well, the first time it does, first time you download the internet and after that it's there. As soon as you change a version number, then it tries to download the new version number, but it stores it locally in the Maven local repository and uses it from there. Yeah, yeah. Unless you tell it not to. Yeah, so we currently set up several builds on the ASF Jenkins machines and they produce on every commit, the snapshots are updated and your Maven will call back and check if something changed once a day. So usually, as soon as midnight, I know it's time to go to bed when it's this one build where it starts contacting Maven central again, so oh, damn, it's 12 again. Have to go to bed. Yeah. There's some font forge. Well, if it's GP, I think we'll have a problem, huh? Well, it depends. Okay. Okay. We'll definitely have a look at that because I don't really. Mm-hmm, yeah. Well then, thank you. Let's grab some lunch.