 Hello everyone Right, so just get started so you know who I am and why I'm standing here I work on both post-crash QL and for enterprise DB. I've been the PG admin project lead for About 19 years now since the project started Also work on the core team of post-crash QL the web and sys admin teams and a couple of our non-profit organizations And the EDB for my day job My official title is vice president chief architect tools and installers What that basically means is I answer questions about code most of the day and commit stuff and occasionally make a cup of coffee So that's me PG admin 3 who's used that before? Yeah, pretty much everyone in the room apart from the sound guy So what is it? What was wrong with it? How do we fix it? Well for many years it was the leading open source GUI management tool for post-crash QL We had millions of downloads a year It was the third generation hence the three Replaced earlier tools that were written in visual basic PG admin one in 1998 which was really my first attempt at any real programming Then PG admin 2 which was me correcting all the mistakes. I made in PG admin 1 We wrote PG admin 3 in C plus plus a couple of reasons for that we wanted to make it cross platform We wanted to be able to handle Unicode multi-bike character sets and so on which is pretty much impossible in VB 5 and 6 And you can you can download PG admin 3 standalone or with the one-click post-crash QL installers from EDB We Supported a number of post-crash databases unlike most of the other community projects We were actually quite friendly towards the the commercial derivatives and had first-class support for EDB's post-crash plus advanced server and Green plums database which is now from Pivotal So I guess everybody's seen a screenshot like that before For those that haven't that's what PG admin 3 looks like kind of dated Which is really the first thing that's wrong with it. It is very dated. It's C plus plus code that goes back to about 2002 Grown quite messy over time One of the one thing that you might not realize is actually really hard to find C plus plus developers in the post-crash community So it was largely maintained by for many years just by a small group of four or five people Which at any one time probably only two or three at most are active The look and feel is kind of dated WX widgets hasn't really changed in many many years And we kind of inherit the look from that And these days there's a lot of lot more people are working on the web, of course You've got cloud installations of databases You're not necessarily doing everything on a desktop and talking to a big box in the server room behind you You know, you might have many people that are working on a cluster of servers that are actually out in Amazon or Azure or somewhere like that We also had problems with the dependencies on some of the third-party libraries in particular WX widgets, which of course we were completely dependent on as some examples there are some bugs that Got reported regularly to us There was very little we could do about them because they were in the underlying WX widgets code I could have patched it for some builds that I do myself, but if you're running on a build For example on Fedora, you're dependent on the WX widgets libraries that ship with Fedora So there's no way for me to get patches into there unless the WX widgets team actually accept them upstream, which Never seems to happen So that got to the point where it caused us so many problems. We were tearing our hair out and not just losing it through old age So we thought about how do we fix this? And eventually decided well, we've really got no choice but to change the whole technology stack That'll make it easier to find developers if we choose something that's more relevant and more widely used in the Postgres community We could make it web-based to satisfy those users that are running out in the cloud and in other environments other than their desktops We can make it easier to change the look and feel HTML CSS we can restyle it change colors change the border radiuses on things move things around really easily compared to WX widgets where we would end up editing XML files that defined the layout of the form But didn't give us the flexibility to change the look and feel of individual controls for example We could also get rid of the very complex and Buggy underlying libraries, which would cause us so many problems The downside of that of course is it means a complete rewrite Which as you can imagine after 15 years of development is a fairly large amount of work So we came up with a plan for PGM in four We had some basic expectations. We want to be able to run in both web and in desktop modes So we want to be able to support the users that are Developing code on their laptops and just want to sit on a plane or on the train or at home Hack on their databases while they're developing their applications just locally on their machines But we also wanted to support the the web use case the cloud use case Obviously we needed a technology stack that was familiar to to Developers and contributors in the Postgres community because that's where we're most likely to get additional contributions from We know the basic functionality of PG admin was what people wanted, you know, it was the most popular management tool and that Spoke well that we wouldn't you know had the features that people needed Maybe not designed in the ideal way But the the basic functionality was pretty much right We did know that there were some features in PG admin 3 that people just didn't use I mean, I'm guessing nobody in this room has ever used PG admin to create an operator family I'm looking for hands, but I'm not expecting to see any In Pete. No, you do use p-sql. I know yeah So so there are a bunch of features like that that we we knew people just were never ever gonna use And they seemed little point in spending the time and effort to rewrite them So We settled on eventually using Python for the back end. It's very mature language. It's been around since the early 90s It's used extensively in the postgresquail.org infrastructure. So whenever you're on any of the postgres websites that we've developed as part of the project You're probably running on it. You're probably looking at a Django based website the Deployment and management platform that the sysadmin team for use for all the servers underneath is written almost extensive exclusively in python And it works very well with postgres. There's a good choice of drivers out there Psycho PG2, which we ended up using is very solid very reliable and Has a very responsively developer who's always open to helping us out with problems On the front end we went for JavaScript jQuery and bootstrap they're fairly Common technologies lots of people know them. They're tried and tested loads of developers out there and To pin it all together on the python and we use the flask micro framework, which is it's sort of like Django, but it's much more lightweight and Where Django is designed for building data-driven applications Flask is more focused on just building the core of an application Now we obviously had a number of both non-functional requirements and functional requirements that we wanted to meet We wanted pg out meant to be a framework primarily so that It can be easily extended So if the postgres guys want to add a shape load or something like that they can very easily do that They've got the apis there. They can write a module drop it into an instance of pg admin in a way you go So what we've ended up with is all the individual tree view nodes of plugins Use case for those is the extensions to support green plum an advanced server both of which have Object types that are not in postgresql The individual tools of plugins so things like the query tool the grant wizard and so on are Using a plug-in API that lets you just add more tools hook them into the menus Get access to the database connections very easily and the database drivers themselves are also plugins so that we can extend the driver to include green plum specific functionality or advanced server functionality or Whatever comes next year We wanted it to be deployable on the desktop as we said and on a web server for multiple users That's a key point When you're running on a web server You don't fire up an application on the web and just start using it like you do on your desktop It's open to the world probably so you're gonna need authentication user accounts and things like that that we never had to deal with before Packaging wise we wanted Windows and Mac packages. We wanted Linux RPMs and Debian packages and a Python wheel for deployment using pip And we need to support all versions of Python that are commonly found on Operating systems used by our users Unfortunately, that's quite a wide range. So if we look back at rail six for example sent us six. It's still using Python 2.6 and yet other more modern Operating systems like the up-to-date fedoras are using the later three series of Python So we had quite a lot of compatibility issues there to deal with We also needed to make sure that we could support one or more servers Simultaneously that was a key feature of Pgabin 3 Pgabin 2 and below really can only connect to one server at a time We wanted to support all Postgres data types As well as ones you can plug in and add to the system Full support for Unicode. So if you're working in Hebrew or Chinese or Japanese or Russian We don't want you to have any problems. We want it to work perfectly for you as well and we want to support Localization internationalization so you can it feels familiar. It's in your home language, you know, eventually we'll have support for Displaying numbers and things with dots or commas as appropriate to your to your particular locale We don't have all of that just yet. Unfortunately, but we're getting there Obviously we want it to be speed to be speedy Fast response. It feels like a desktop application. We don't want it to feel like a website when it's running on your on your desktop and Key to that is having No full page reloads. So everything we do is Ajax base. So If you if any of you have ever used the old Pg out a PHP Pg admin application that was released years and years ago Pretty much every time you did anything in that it would reload the whole page and show you the new view We didn't want any of that We want it to look and feel like it's running on the desktop even though it's in your browser and a number of functional requirements Support for all the common database object types. So this is the bit where we dropped Stevens operator families sorry Query tool Pg admin 3 had two separate tools query tool and the view data tool You could run queries in the query tool and see the results You could view the contents of tables in the view data tool and edit those query results directly in the grid Essentially, though, they're basically one tool So we wanted to merge them together and over time add more and more smarts to it So that we get to the point where you can run an arbitrary query And it will figure out on the fly if you can update the results or not Not quite there yet. You know, we're out as I say, we're adding more and more smarts But we do we have done it as one tool to begin with that just runs in two modes at the moment We wanted some dashboards for simple real-time monitoring something Pg admin 3 never had Procedural language debugger, which a lot of people find very useful grant wizard for Managing the access control lists on your objects and the ability to run things like backup and restore The ability to do maintenance operations run vacuum analyze and so on As well as various small utilities, you know being able to pause and resume while replay or add named restore points Allowing users to understand what they're doing is critical. So we've got online help for The actual use of the application then describing what the different dialogues do and how to use each of the buttons and so on but what we also have is links to The the documentation for for either PostgreSQL or advanced server as appropriate So when you're editing a table, you can press a button and get straight to the create table SQL syntax documentation to help you understand Not just how the the application is working through the application documentation, but also what the underlying SQL is doing We also needed a user manager with self-service password management and so on so that when you're in Multi-user mode you can log in and the system is secure so How do we build all of this? So for the first year or so I was just developing code and sort of prototyping and building the core infrastructure And then at that point once I got it the way I wanted it. I was able to use a bunch of staff at EDB and That really helped because I was able to boss them around basically One of the problems you often have with open-source projects is people don't tend to work for you. They're all volunteers so actually having a Well-defined project that you're trying to get x y and z done in a very short time frame Unless you've got very cooperative volunteers is very hard to do So it made it much easier because I was able to use some of the staff at work To do much of this work for us We had a fairly large team that so the guys worked on this for about a year Probably about nine months until we got the first release out Three developers and committers who'd worked on PG admin for a long time That's myself a Shesh Vashy and Akshay Joshi And then there were six other developers a designer project manager for QA people two technical writers the lead one of which wrote the Basically the first ever PostgreSQL book that was released Three guys working on the packaging And then in the community we have we've had something like 40 Individual contributors just with anything from typo fixes to two more complex changes And that was our first sign that this was a good move because all of a sudden we've gone from a C++ app that rarely had anyone writing any fixes To the first version of an application having nearly 40 people Actually helping us get it right that were outside of the core development team We had about 75 people as well reporting bugs which Bugs are inevitable. We want to know where they are and how to trigger them We had a couple of constraints that we had to work within The team that we're doing the work mostly were the PostgreSQL Enterprise Manager team at EDB That's our enterprise management tool So they needed to start work after PEM 6 was released Finish in time for the PEM 7 work that they're currently doing right now Also allow needed to allow time for any updates that we had to do in the meantime And also allow time for any support escalations within the company We also needed to make sure that the code was ready to go out in the PostgreSQL 9.6 installers Because we've always released new versions of PG admin with the new version of PostgreSQL So it was a fairly heavy set of constraints to try and meet And as such it took a fair amount of management to figure out how we could get everything done in that time frame We used fairly traditional methods. We weren't using a full agile Method or anything like that because it makes it very difficult to predict where you're going to be in a year's time When you're using agile methodologies So we were using a product called project manager where we As you would expect estimated each individual task figured out what they all were assign them to people Sequence did all up and so on When we came to patch management that also proved to be difficult because At the beginning I was the only one dealing with patches and I might get 20 30 patches a week Which is a fairly significant amount for one person to deal with So we ended up using a camera and chart to actually manage the patches through the various stages of review Back to developer in review again, and then committed and so on then once we actually released we moved everything across to the community's red mine installation Which is where we where we have things like the bug track as now there's a Quick screenshot of the the project management plan I think there was if I remember rightly there was something like 400 tasks on there For the whole project just to build the basic features that we needed and it spanned about nine months So as you can imagine that was a pretty complex plan to manage and there's the just a screenshot of the Kanban chart that was used for the Patch review so we've got the in development column review committed bugs transferred to red mine I think there were a couple of others that you can't see on there now But we've basically stopped using this now that we've got the the first version out the door One of the key things in getting a project out so quickly is that we have good quality assurance You know we don't want to just write code and throw it out the door And there were various things we should to try and make it as high quality code as possible So I managed to steal some of the QA team at EDB and In getting them in testing as we went through they developed manual test cases based on the Code that was being committed and the individual tasks that were being done and Used the system that they they use generally called test rail which allows them to track test runs and passes and failures and so on One of their guys also built our first automated test framework which was built on Python 2's unit test module that allows us to do testing of the REST APIs that the Python code provides for the front-end code and we've also Added automated testing and I've given this talk before and in previous slides It used to say coming soon now or something like that But as of this morning it now says framework developed post one by post one point two by pivotal labs Well, I'll talk more about later on But that's integrated into the Python test framework and uses Selenium so that we can run tests that literally go right from the browser through to the back end We also had quite a bit of community testing the problem with that is it tends to be very ad hoc You know, there's no People playing with the code in the community literally would just download it and play with it They're not going to go through any test plans They're not going to go through any rigorous process to make sure there's good coverage of everything and so on So whilst it's greatly appreciated and essential We can't rely on that sort of testing alone We did get a lot of very good feedback from the testers. We did get some negative feedback as well We'll talk about some of that in a little bit But you always get negative feedback. So we you know, we carry on regardless and we we take on board what we're told And there's a just a quick screenshot of the regression tests, which just run automatically One after the other across multiple databases depending on how you've got the system configured so Give you an idea of the release timeline the first time I gave this talk. There was about two lines on this slide This is probably the last time I'm going to give this talk as it is now I think I've done it three times around the world now and this slide's got a little bit bigger each time We've just released 1.3 on the 10th of March about three weeks ago As you can see, we're actively fixing bugs in each new version and Adding new features, which is something we never did in PG admin 3. We were very strict about never adding new features Because PG admin 4 is so new and because a lot of users are used to all the features in PG admin 3 What we found is some of the ones that we thought we need didn't need we actually do So we're being a bit more relaxed about adding new things now And again, we'll talk about it tomorrow on one of the later slides That was a little screenshot. I took on Sunday I know it says as of 10th of March, but I guess that's the last time open hub scanned the repo So you can see the the activity throughout 2016 just basically shot up and the Size of the code base increased drastically as the project progressed The open hub site I haven't included a screenshot of it But open hub actually reckoned the project is worth about three and a half million dollars at this point based on estimates The reality is there's some libraries in the source tree, which are not ours if you take those out It's probably a down to about two million But it's a pretty large number. I was very surprised when I saw that. I know we put in a lot of effort, but it's Still surprising a number Give you an idea of how much code there is now One of our audience members and I were just talking about the ratio of Python to JavaScript in the code base earlier I originally thought it was going to be largely Python probably, you know, 75% Python and 25% JavaScript It's turned out and as I was rightly corrected earlier. It's such a UI in front-end heavy app that it's It's no real surprise when you think about it that actually most of the code is JavaScript so 152,000 lines and When I took that I did Try and exclude all the libraries that were not ours that we were just using So about 44,000 lines of Python You add all of that up and over a quarter of a million lines of code Now obviously we should all get paid by lines of code. We write right So I reckon I'm do a pretty big bonus so post release and Anyone who's seen this talk before you won't have seen this bit because this is the bit I wrote at the weekend while I was sat in my hotel room all day The teams expanded a lot The pivotal labs have started working on PG admin now because they want to add green plumb support And they also want to contribute to further enhancements and improving various features the application They're not just providing development Expertise, but they've got project managers looking and looking at User stories understanding what the users want by interviewing them and talking to them Doing workshops and similar things And then designing features based on that feedback We're hoping to do more and more of that as we we move forward so that when we improve PG admin It's not based on what we think people want anymore But it starts to become more and more based on what the users tell us they want Aside from that I mean it's great having the pivotal guys on board because they've really diversified the experience in the PG admin team Most of whom have come from PG admin 3 originally have been learning new technologies The the pivotal team have a lot more experience than we do on the the web code And have been able to bring some some really good new ideas to the to the table They've also provided additional test suites the selenium based one that I mentioned earlier and another jazz Test suite based on Jasmine for unit testing the JavaScript code And obviously I work here on features fixes and helping us Work with more of formal design process You know we we obviously have to run the original project in a fairly formal way Otherwise we wouldn't have been successful, but moving forward. We're trying to improve now In PG admin 3 we were just design features based on what we want and as I said where we have the benefit of People now looking and really and trying to understand what users need We're also syncing up between the teams regularly, which is which is good So it's not just a collaboration on the mailing list, but we're you know We're also talking to each other and Really planning in depth where we're going which is great There's a little screenshot of some of the work that has been done What we've found is users want various things out of the history and the query tool And this apparently is proving to be pretty popular A feat and pretty popular feature request So what we have here is basically a mock-up of the new history that would eventually be persistent So instead of just being for that session you're currently running you could go back and look at the queries you ran last Tuesday for example You can see very clearly the error messages that came any notices at the bottom that came when you ran it as Well as the full query text which you can just copy and paste back in and run again if you want to So there's one example of the great work that the guys that pivotal have been contributing Not sure what release this is going to be in just yet. It's still being fine-tuned and worked on But I'm hoping to see it in the next couple of months I'm looking for nods from the back corner of the room Sorry Couple of weeks next couple of weeks, please guys So some of the things we've learned bugs are inevitable You know, we have professional QA people that have been helping us with PG admin But no matter what you do how much you test there will always be bugs in horrendously complex bits of software like this You know, we've got hundreds of features If you count up every little last thing you can do every bit of sequel that you can generate through the UI and so on Thousands of options if you think you can all the different data types You could create on columns and whether or not their primary keys or whether or not they're unique and all the constraints you can put on them Supporting six versions of Python 10 supported databases 11 when the the Green Plum compatibility work is finished and Five core browsers each of which have lots of different versions out there and some of which evolve very very rapidly So you can imagine there are millions of combinations of things you can do and run PG admin in so there's no way you're going to do a manual a fully comprehensive manual test of all those possible combinations of Of options and software versions and so on and there's no way you're going to do it in an automated fashion either But we needs to do Whatever we can to try and minimize those bugs of course regardless so testing PG admin 3 never had any test suites at all it was Released every time with us just clicking through trying it. Can I connect to a database? Yep. Can I run a sequel query? Yep, can I open the help file? Yep done release it, you know, it literally was Sort of Saturday afternoon hobby hacking. I mean, that's how the project started Nowadays we've got The three automated test suites They are being run for every check-in there's a Jenkins server that I'm running That is building everything it can possibly build running all of the automated tests against every supported database on every single version of Python And we're continuing to add to that suite as and when we find bugs We're going to be enhancing the suite to make sure those bugs don't come back as and when we build new features We'll be enhancing the suite to make sure that those features work as they're supposed to so We're never going to get it perfect But we're really concentrating on Testing these days and making sure that everything we write is going to be testable moving forwards We found there were performance issues shock horror Who'd have thought something might be slow on a computer these days So pgm-in4 in a desktop app is always going to be slower than a native application Right It's a web app. It's running in a Python interpreter and it's being rendered on what basically as a web browser With the best will in the world is never going to be as fast as a native C++ app But we never really expected it to be a problem practically speaking and in most cases it actually isn't what we found though users are actually very sensitive to To delays that they perceive when they're running there at the application if the query tool takes a second to load Practically speaking it doesn't stop you doing anything. It's not going to slow you down because You that second is when you're figuring out where to put the mouse next and what you're going to type, right? The reality is that the perception of Slowness is something that tends to annoy users regardless So we're doing a lot of work at the moment to try and address that and make everything as optimized and as fast as possible Interestingly, I've never heard anyone complain when they are intentionally running in web mode. I Think it's because people expect websites to be slow and expect things running in their web browser to be slow. Yes We have the desktop mode Primarily because we we don't expect everybody to be running a web server if you're if you're running a Windows machine You don't want to have pg. I've been running as a server behind a web Server all day long every day. So we wanted it to be a Design such that you could just open it like a regular application run it close it and it stops again So The desktop runtime that does that for us is basically some C++ code that glues together A browser engine and a Python interpreter into one app. So it starts up. It loads the Python code and then it renders it so One of the changes that we have made to improve the speed already is We've rewritten the query tool and the way the results are handled and the data is transferred back to the query tool for rendering in the grid We basically redesigned the JSON data structure that she used behind it and of in some cases Reduced the amount of data that's transferred by up to 70% And that actually had a fairly noticeable Performance improvement with it. We've also got various ideas that we're we're playing with at the moment and I think pivotal are doing some work on this right now to optimize the JavaScript css and HTML So that we can minimize the data transfer size for that and the number of round trips and the amount of template rendering that We do and so on now. We spoke about the desktop runtime. We've had a number of problems with that as well, which we've Primarily found when it's been in the hands of users. We found that it tends to work well for most people but we have a There are a number of situations where it just doesn't seem to work so well We found first of all that embedding browsers and applications is actually hard to do and to get right We've also found that Qt web kit has got rendering bugs We use Qt web kit in the first two versions of pgabin 4 It has now since been deprecated in Qt 5.5 in favor of Qt web engine, which is based on chromium However, that can be significantly slower for some users and makes them complain It can also have some fairly nasty rendering issues over RDP connections. That's the Microsoft remote desktop protocol We think it's to do with the graphics cards on the server It's running on but some users report seeing a blank just a black screen when they load the application There are other reports of people also using Qt web engine for other applications that have seen the same issues We also run into problems with the visual studio run times newer versions of Qt web engine are dependent on Visual C 2015 which is Because chromium the underlying browser on which it's based has moved to that as its minimum browser because I think they use some some of the C++ 2011 spec code these days or functionality However, that's incompatible with the edb postgres packages, which use Visual C 2013 As does Python 2.7, which we use underneath Now for those of you that are not familiar with C and C++ you basically don't want to mix runtime versions in a single application Because if any pointers or data structures get passed between the two seriously bad things can happen so that causes us Pain, you know, we can make things work But the whole ecosystem of other things that we rely on suddenly becomes this incompatible mess And makes it very difficult Solving that problem. We've looked at some other options Chrome embedded framework, although that also requires visual C 2015 But it does potentially solve some of the speed and rendering issues We looked at whether or not we can securely launch an existing browser. So when you start the app It's basically just the Python interpreter that then runs your existing browser on the system The problem with that is we need to pass a security key to the browser So that only you can connect to the server that's running if you're on a multi-user system You don't want somebody else pointing their browser at your PG admin server The difficulty there is the only way to pass that key is on the URL that you pass to the browser and That means it's going through the command line, which on Windows is not a problem But on Linux system anyone who can PS minus EF Then gets to see that URL with the security key in it So that's that's a fun problem Well, I also found though on Sunday when I was sitting in my hotel room being boring That a bunch of guys have actually started a project called QT webkit reloaded They've also run into the QT web engine issues that we've run into so they've taken the old QT web code they've brought it up to date with the latest versions of Webkit and made it a lot more stable fixed a number of bugs and so on I Tried it on my Mac and it actually seems to work really well So as soon as I get home, I'm hoping I can get it to work on Windows as well And maybe that will solve our problems We also found unicode support is really hard in Python Because we're supporting both Python 2.6 and 3.3 and above and 3.3 and above We have to deal with the different ways that unicode is supported in those two versions of Python Python 2 doesn't use unicode by default Although it can do and Python 3 does it does use unicode by default So you'd think with a few if statements here and there you could deal with that Unfortunately, it's not quite that simple because it never is What we found was that Python 2 uses the ANSI API calls on Windows So when you're executing executing external processes like PG dump and PG restore through Python You can't pass unicode characters to to those utilities So you can't PG dump a database with a Chinese name, for example Because Python is using the ANSI version of the API instead of the wide character version So that's a difficult problem as well We're probably gonna have to figure out how we can build the packages for Windows using Python 3 and deprecate Python 2 on that platform Postgres also supports lots of other character sets and they're not all 100% compatible with unicode Which was specifically UTF-8 Which also potentially causes us some some much more limited problems, but still ones that we need to solve We also found that some users missed features You know, we dropped various features that we thought people didn't use You know, we had fairly limited audience that we were able to actually poll when we were figuring out what to include and what not to include And inevitably when you've suddenly got 200,000 people downloading version one That application is in a is a much bigger audience than you you polled when you asked what you could get rid of SSL certificate based authentication, for example, we've had a number of people asked for that back The host address option one of Steven's old colleagues asked me for that blank Because they use it in a Kerberos environment for doing their authentication That's just one field on the connection dialogue SSH tunneling which never even worked out well in PG admin 3 because it was another one of these buggy underlying libraries You know, I've had a bunch of people ask for it back again And other things like we had a database restriction field where you could put Basically part of a sequel where clause in your configuration So it would only show you databases that matched that that restriction that you put in The idea being that if you're in a say a school and there's a database for every student Each student could just put effectively where database name equals my database So it hides the other 60 from And the scratch pad Very simple. It's just a text area on the screen that was designed for you just to use for copying and pasting things into Or writing notes in and things like that. I've had a few people ask for that back. I Just use my editor, but people like it in the application. So so that's about where we are now that's a Hopefully give you an idea of some of the things we're looking at where we're going to at the moment We're continuing to fix bugs add new features make the code more efficient more solid and Just basically make it better and you know, hopefully it will still be around in another 15 years like PG I mean three was and I do hope that we don't have to rewrite it before I get to retire Which would be nice So I Didn't have a slide here that said demo. I pulled that out when I Rewrite the end because it made the talk quite a bit longer. I believe I've got about five minutes left And it did then I realized afterwards it said in the description of this talk on the the conference website that it includes a demo of the product I can answer some questions for five minutes or I can Shut up and go away and catch my plane if you prefer or Or we can have a very quick look at the application if you want Any Yeah No on On OS X it's an app bundle in a disk image. Do you drag it and drop it into your applications folder and away you go? It's completely self-contained Well, it was on Mac it will use the system Python It ships with a virtual environment of its own that's pre-configured, but it will use the system Python interpreter on Windows Again, it is self-contained on Windows. It is an installer. It will stall into the program files or wherever you direct it to The big difference there is that it does include a Python executable on libraries as well Because Windows doesn't have Python by default Yeah, the RPM packages will just dump things in the relevant Python directories they tend to be a bit more spread out Right now the really the main new feature is just the dashboard so when you I can get this to Come out so when you log in for example you get the welcome dashboard Well, which is designed to help guide you on what to do next you've got quick links to configure or add a server and so on And if you click on Click on a database or a database server Actually have my Rendering cycle turned right down so the graphs are taking a little while to render But it gives you a quick view of monitoring What what the system is doing? I think I've got these sampling every 10 seconds, but the default is every one second Aside from that and the ability to run multi-user on the web We haven't really added any new features yet. What we've done is redesigned various things to make them easier So for example when you create a table in pgabin 3 you don't want to create table dialogue Then you go to the columns tab and then you click a button to add a column and a pop up another dialogue And you'd fill that in hit okay, and then Love the rinse repeat. So we've done a lot of optimizations in usability where we've redesigned those sort of patterns Such that you can just type straight into a grid if you want or you can expand the row in a grid So primarily the focus has been on avoiding the need to have lots of pop-up dialogues and and so on and make it much faster to To define the table as you want Moving forward is when really from here on is when we start to think about new features Starting primarily with the work digitalist the gun Yeah, so if you think back to 2002 when postgres 7.3 Was the current version something like that? We didn't have roles at all. We had users and groups and Then so when we added support for roles what we did in pgabin 3 was Users to try and avoid confusing users too much. We called them group roles and login roles To try and sort of keep that same sort of design One of the choices we made in pgabin 4 was we're going to just treat them as roles Because that's what they are in the database now you'll notice that Basically if the can log in flag is set you'll get the little icon that just looks like one person and if the Can log in flag is not set then you get the multi-person icon So that's how you can tell it a glance whether it's a group role or a login role plus a question look at the properties Yeah, so as I mentioned the UI is plugable so each one of these nodes is just basically a drop-in Python package That's discovered it automatically at load time and includes various bits of CSS and JavaScript and HTML that it needs to To render its dialogues and so on They're pretty easy to build so you can just take one of those nodes and copy and paste it and edit it as you need to and also tools like the Being a database I think tools like the Yeah, gotcha tools like the ground wizard Also plugins that just hook into the menu and are auto discovered at launch time There's documentation in the online docs about the API's Although it's not overly extensive at the moment I'm told I've got a stop. So I think we managed to get something vaguely approaching a Demo in there as well as some questions. So thank you very much for listening Please download