Thanks for the interest. I added now a new blog post in which I detail an investigation scenario of a Postgres DB with the GTInspector: http://www.humane-assessment.com/blog/dynamic-exploration-of-a-postgres-db-with-the-gtinspector/
The post includes a video that kind of gets you through the most important parts: - use the playground - query the DB and preview the results through dedicated presentations - navigate through objects and code to learn the API - build a visualization in place and continue exploration - extend the inspector with a dedicated presentation Please let me know what you think. Cheers, Doru On Sat, Mar 8, 2014 at 8:48 AM, [email protected] <[email protected]>wrote: > Doru, > > Where to look on your blog for a view on the essentials of this? I see > http://www.humane-assessment.com/blog/making-the-pharo-settings-browser-open-faster-with-gtinspector/for > example. A video? > > I look at the blog and vids but it is a bit hard to find a basic demo to > grasp things. > > TIA > Phil > > > On Sat, Mar 8, 2014 at 8:16 AM, Tudor Girba <[email protected]> wrote: > >> I hope not. What are we trying to optimize? >> >> If you look closely at the GT work, you might notice that it is not just >> a tool, it's a whole new philosophy for coding. The EyeInspector picked >> only one aspect out of a whole. >> >> One high goal is to change programming such that the inspector + debugger >> to capture most of the coding experience. This is what live means. Right >> now, in the default Pharo we only code small things in the debugger and >> nothing in the inspector. We work on the idea of a moldable IDE that will >> change all that. >> >> Let's look at some facts. Right now, in my image I have 75 different >> extensions for GTInspector. And the total amount of lines of code has >> barely passed 1000 LOC (including all utility code). These are not just >> independent views, but they are combinable. The amount of use cases >> supported span a wide range: querying source code, visualizing performance, >> navigating file system, querying DB, and more (read the posts from >> humane-assessment.com for hints in this direction). >> >> We programmed most of these extensions from within the inspector both >> because it's fun and because it's significantly more productive. And I am >> not the only one. This power is not serendipity, it's by design. And we >> only started to untap this potential. >> >> There is still a long way for the concept of inspector and I believe >> there is a large payoff in it, too. >> >> Optimizing for a small thing now should not be the way to go :) >> >> Cheers, >> Doru >> >> >> >> >> On Fri, Mar 7, 2014 at 11:23 PM, Sven Van Caekenberghe <[email protected]>wrote: >> >>> Well I would hope that some kind of convergence would be possible in the >>> future. Maybe some kind of abstract meta description like magritte, that >>> different tools can use. >>> >>> On 07 Mar 2014, at 16:43, Yuriy Tymchuk <[email protected]> wrote: >>> >>> > Hi everyone. >>> > >>> > This day I've attended Moose dojo and I'm pretty impressed with the >>> possibilities of GTInspector. The one thing that I've noticed is that both >>> GTInspactor and EyeInspector support custom inspections for objects. I'm >>> wandering if we can come up with a common protocol to give an object >>> specific infector view, and not develop a separate thing for each inspector. >>> > >>> > Uko >>> >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"
