00:00:06.740
Okay, my name is Jeff Barczewski, and I'm here to talk today about Masterview, the evolution of a WYSIWYG template engine. I was the founder of the Masterview project, and I have a company called Inspired Horizons that does training and mentoring.
00:00:12.000
What I thought would be good to discuss today is a little background on why we created the project—essentially, the thought process we went through, some of the goals that we had for the project, and I will give you a demonstration of how things work. A lot of you probably haven't seen it yet, and I can talk through exactly how Masterview works. Following the demo, we will talk about the evolution of how it started and how we grew the project. I think a lot of the lessons we learned could be applicable to many of your projects. Lastly, we can finish off with future directions on where we plan to take the project.
00:01:09.299
So, just to back up, I'm an assistant architect for RGA in St. Louis, Missouri. Primarily, there, we build a tele-underwriting application in Java. I went to a No Fluff Just Stuff Java conference in February of 2005, wanting to learn about the newest Java technologies, but I came out wanting to learn Ruby—that was pretty cool, and my life has changed ever since.
00:01:24.060
At that point in my career, I had been working with Java for 18 years, and I was pretty much tired of it. We were using frameworks like Struts for web applications, but it felt boring and overly complicated. Making screen changes required a lot of effort, and I lost interest in looking at new Java technologies.
00:01:35.840
I attended the No Fluff Just Stuff conference hoping to see something worthwhile, and I heard Dave Thomas speak, who provided some insights. Then I saw Bruce Tate's talk on 'Beyond Java,' where he pointed out that many Java projects were well attended simply because traditional Java methods like EJBs were too difficult. He highlighted how lighter-weight frameworks like Spring were trying to bridge this gap. That's when Ruby, particularly with Rails, caught my attention. The idea of significant productivity gains was enticing—I remember him claiming a tenfold productivity increase, and that intrigued me.
00:02:06.739
So I began exploring Ruby. I started attending the St. Louis Ruby User Group that had just started, and it was exciting to see what people could achieve with Ruby. I was invigorated and excited to learn and code again after feeling stagnant for a long time. I needed an effective way to develop WYSIWYG templates for websites, and I wanted to use Rails as my back end.
00:02:34.920
After reading about the philosophies of Rails architects such as David Heinemeier Hansson, I realized they didn't have a need for a dedicated template engine, as they believed Rails’ way was best. However, I felt there was room for improvement there. I started with a couple of projects using Rails, but it felt lacking. It seemed like going backward as I was primarily using ERB templates, which reminded me of the old ASP or JSP days.
00:02:58.320
In Rails, I felt like I was embedding Ruby code into the middle of HTML awkwardly. They were also breaking things into different files for the sake of being DRY. I felt that we could certainly do better than that. So I explored the options available and found various WYSIWYG engines in Ruby but they didn’t meet my needs, nor could I easily extend them.
00:03:48.059
That's when I contemplated my project. My journey to learn Ruby and Rails began back in March 2005, and I was amazed by the productivity I achieved. I wanted to create something WYSIWYG capable so users could use editors like NVU or Dreamweaver to move things around on the screen, especially those who weren't developers but wanted to participate in the design process. I aimed to keep it simple and fast, without adding unnecessary complexity.
00:04:30.299
I desired to leverage Rails layouts, partials, and helpers. The layouts would provide the header and footer structure, while partials would be used for reusable pieces within the page. Helpers would give functionality wrapped up in function calls so that rendering could be simplified. Attempting to fit this into existing libraries proved challenging, as they complicated matters more than they solved.
00:05:11.699
I wanted scaffolding to offer a quick wow factor, making it easy to create CRUD applications or admin apps, as sometimes that’s all that was needed. Plus, I wanted to minimize the number of files.One of the frustrations with Rails was having to jump between different files.
00:05:52.500
For instance, to apply a look and feel to a site, you might go to one file, realize that's not right, and then jump to a layout and then a partial. This was cumbersome and complicating for users trying to implement visual changes. So, I wanted to avoid this hassle.
00:06:44.940
Moreover, I desired a straightforward way for templates to be previewed in the browser. It was important for me that designers could use these templates and have the ability to make live changes to content without needing the full Rails application running. They could then present it to stakeholders and make adjustments on the fly as needed, integrating these changes back into the application.
00:07:16.760
Of course, when starting any new project, one should realistically look for existing solutions before building something entirely from scratch. I engaged with the community, seeking advice and recommendations on available projects. I was particularly interested in component-based solutions.
00:07:54.420
One of the challenges I encountered was figuring out how to best use existing frameworks while fulfilling my needs. I explored various Ruby templating engines, including Amrita and Quartz, but I found that none quite met my requirements. While Amrita was slightly closer, I realized the existing options were too inflexible.
00:08:49.320
Eventually, after much thought and numerous discussions with the St. Louis Ruby User Group, I decided I needed to create my own project. My journey to learn Rails was underway, and I was eager to innovate something that could offer the features I envisioned.
00:09:18.480
I had a strong urge to create a WYSIWYG template generator. That march towards creating Masterview involves defining my goals: it would be WYSIWYG capable, simple to use, fast, efficient, DRY, and capable of taking advantage of Ruby and Rails' existing components.
00:10:13.560
I also wanted the ability for the community to be able to contribute—users could create their own tags or directives that would extend functionality. This would not only allow the project to evolve but also welcome contributions from different users with diverse needs.
00:11:10.440
Having articulated my goals and discussed them in the Ruby User Group, everyone seemed supportive of my concept. They appreciated that I'd created a way for WYSIWYG templates to be generated while leveraging Rails, and they could see the potential for such a flexible tool.
00:11:53.520
Moving forward, I would begin to demonstrate how Masterview operates, drawing comparisons between a standard Rails application and what Masterview could achieve. The excitement both from me and the Ruby community was palpable as we embarked on this journey together.
00:12:40.680
As I generated a new Rails application, I would illustrate the differences while lining up various functionalities with Masterview. This would clarify how this new template engine operated within the Rails framework.
00:13:15.900
To set the stage for the demonstration, I clarified that while I would be utilizing Rails for this project, Masterview itself is not tied exclusively to Rails; it is a Ruby template engine, allowing it to stand alone.
00:14:04.200
There were numerous interesting projects in the Ruby ecosystem that interface well with Masterview, and this could expand the possibilities for integration. I focused on developing a quick demonstration to get my key points across.
00:14:55.740
During my demo, I walked through the scaffold generation process for a product catalog, and I would showcase how Masterview simplifies workflows compared to traditional Rails applications. By generating and interacting with the database through this application, I framed how Masterview can facilitate enhanced productivity.
00:15:43.560
I demonstrated the process of setting up a product table, scaffolding that, and showcasing the various interactions: creating, deleting, and navigating various elements of the application.
00:16:34.620
Initially, my demo faced challenges as I navigated through the setup, encountering database configuration issues. However, I approached these hiccups with humor, understanding that live demos often come with their own quirks.
00:17:40.560
The excitement built as I successfully scaffolded my Rails app into a functional store application. The core functionalities displayed—namely, creating, editing, deleting, and viewing entries—illustrated the seamless experience offered by the template engine.
00:18:26.640
Then, I transitioned to showcase Masterview, highlighting its unique approach to templating and how users could install it as a gem, integrating it into their existing workflows seamlessly.
00:19:17.520
In my overview, I detailed how Masterview could streamline the process for users, emphasizing how templates were more seamlessly integrated into their workflow than in traditional Rails setups.
00:19:55.440
After generating several HTML files using Masterview, I navigated through the application demonstrating how users would interact with the generated product tables, showcasing the ease of transition from concept to prototype.
00:20:50.280
As I introduced multiple styling options, I reiterated that Masterview not only allows users to focus on creating but also enhances their prototyping capabilities, ensuring that changes made reflect instantly.
00:21:46.480
I discussed the feasibility of displaying JavaScript-enhanced functionality within the framework, enabling real-time interaction with templates. It was emphasized that while some projects may seek extensive sophistication, Masterview aims to make development feel straightforward.
00:22:43.800
Next, I turned the discussion towards the ongoing development process behind Masterview, where I shared how we leveraged feedback to consistently evolve the template engine based on community engagement.
00:23:40.680
Reflecting on challenges, I noted how early versions lacked in collaborative scope. Encouraging user contributions significantly enhanced the project, creating avenues for not just improvement but user engagement.
00:24:35.760
I introduced the concept of TDD into our development process, emphasizing how critical it became to safeguard the integrity and functionality of Masterview. This commitment to rigorous testing led to substantial optimizations throughout the architecture.
00:25:23.280
Over time, we recognized that complexity in our API led to challenges for new users. This factor catalyzed a re-evaluation of how we could significantly clean and simplify user interactions with the platform.
00:26:16.440
I noted the process of refining the DSL further; users experienced significantly cleaner interactions that emphasized less friction and improved usability within the project.
00:27:04.760
We then ventured into creating a more robust tool with rich directives that cater to diverse architectures in various use cases; the focus shifted towards community-driven desire in anticipating user needs.
00:28:01.440
Finally, the presentation leaned toward looking at more powerful directives, such as enhanced pagination features, while leveraging the strong capabilities existing within the Rails framework.
00:28:50.520
As I wrapped up my presentation, I emphasized the importance of collaboration within the Ruby community and how this has fostered dynamic growth in projects like Masterview. I expressed my eagerness to engage further, sharing the resource websites where all the documentation on Masterview will reside.
00:29:49.440
I invited participants to contribute any feedback and questions, providing my contact details for any follow-ups. I noted how exciting it has been to be part of such a friendly community, which reinforces the value of collaboration for developers.
00:30:48.480
I thank the audience for their time, reiterating the immense potential of what Masterview could offer, especially with community contributions, and how open-source advancements could define future paths—all while staying grounded in the fundamentals of Ruby that make it so special.
