View from the Edge

OpenEdge Architect videos on Communities

With Exchange Online 2009 coming right up (September 15-17) I wanted to remind people of the availability of a set of introductory videos that cover a lot of the basic topics related to using OpenEdge Architect. They're all available directly from the OpenEdge home page on the PSDN area of Progress Communities:

http://communities.progress.com/pcom/community/psdn/openedge

There's a landing page for five introductory videos to get you started using Architect for the first time, covering topics such as creating your first Architect workspace and project, defining database connections for your workspace, setting project properties, building and running your project, and using the ABL Editor that's a central part of the value of developing in OpenEdge Architect. That page is here:

http://communities.progress.com/pcom/docs/DOC-101140

And then there's a continuing series of topics that go beyond the Getting Started series covering subjects such as defining and using perspectives and views, maintaining structured procedures created in the AppBuilder, using the ABL Debugger, and various more advanced features of the ABL Editor. Those sessions are all available here:

http://communities.progress.com/pcom/docs/DOC-101504

The videos are designed to be fairly self-contained, so that you can view what's of interest to you, though there is a recommended sequence to them that's indicated by their organization on the site. And they're kept to around seven or eight minutes each so that you're not overwhelmed with content and can try out what you've learned in each video before proceeding.

We're very interested in your feedback both on this specific set of presentations and on the general format that they use. We're already creating new video series, some accompanied by documents with text and code samples, to help you get started with other major parts of OpenEdge 10, including the support for classes and the GUI for .NET. Keep us posted on your comments and recommendations.

GUI presentation models - more than just look and feel

While working on a new ABL sample using OpenEdge GUI for .NET, I started thinking about the different presentation models that are available to an ABL programmer in 10.2A. While much of Microsoft geeks are focused on the cool new features of Vista, OpenEdge stays focused on real world business applications. Business applications need a productive, full-featured user interface whose purpose goes beyond catching the user’s attention. Since these applications must be functional above all else, the need for Vista’s multimedia effects (video, animation, graphics) might be nice but not critical. Business applications have a typical set of features that are often reused over and over again. These features include:

• Support Create, Read, Update, Delete (CRUD) capabilities – data entry and persistence
• Data managed in a grid or multiple entry fields

One of ABL’s core strengths has always been its ability to manage the backend data easily, with built-in and native data awareness and transactional support in the language. Now with OpenEdge GUI for .NET, you have even more choices available to select the right presentation model for your applications. In general business applications have many different screens to show to their users and often there is need to show more than one simultaneously. There usually is a central way of managing the various screens (a window manager), as well as some means of transitioning between them. It is crucial that users can easily navigate the application, and can use it in a flexible way that fits with their needs.

The presentation models to consider are:

• Single Document Interface (SDI)
• Multiple Document Interface (MDI)
• Tabbed Document Interface (TDI)
• IDE Style Interface (IDE)

Single Document Interface

SDI organizes graphical user interface applications into individual windows that the operating system's window manager handles separately. Each window contains its own menu or toolbar – there is no concept of a “parent” window. Applications which allow the editing of more than one document at a time, e.g. word processors give the user the impression that more than one instance of an application is open instead of a single application with multiple documents. Each window displays as an individual entry in the operating system's task bar or manager – which might group windows of the same application.

          Microsoft Word and Excel are examples of an SDI application.

Multiple Document Interface

MDI organizes graphical user interface applications into many windows that reside under a single parent as opposed to all windows being separate from each other like SDI. A single menu bar and/or toolbaris shared between all child windows, reducing clutter and increasing available screen space. In MDI a single instance of the application is shared and the child windows all float within the parent (container) window.

The disadvantage of MDI is that it is easy to “lose” a child window when many windows are open simultaneously. In order to view the list of windows open in MDI applications the user typically has to go to the menu bar, moving their focus out of the child window area.

Tabbed Document Interface

This is a specialization of the MDI model. Like MDI, TDI organizes graphical user interface applications into many windows that reside under a single parent window. Unlike the floating child windows of MDI, in TDI each “window” is displayed in its own tab. This makes it much easier to find open windows than traditional MDI. TDI windows must always be maximized inside their parent window, and as a result only one tab can be viewed at a time.

The disadvantage of TDI is with only a single window available at a time, comparing information or copy-and-pasting between two windows is more difficult. Additionally although tabs make it easier to find open child windows, if there are a large number of windows opened simultaneously there are many tabs for the user to search before finding the one they are looking for.

Firefox is an example of a TDI application.

IDE Style Interface

IDE Style Interface is another specialization of the MDI model. Like MDI, IDE organizes graphical user interface applications into many windows that reside under a single parent window. An IDE-style interface is a superset of the MDI model with features available to support the child windows that are not normally available in traditional MDI applications. These child-window features include:

• TDI model for child window
• Ability to view child windows simultaneously using splitter
• Separate window management for child windows - normally tree-based
• Additional, independent panels to support application – these often use a tabbed interface

Microsoft Visual Studio.NET and Eclipse are examples of IDE applications.

Microsoft Outlook

Microsoft Outlook, and its very popular user interface metaphor, is not true to any of these models. It is closest to an IDE application without tabs for the child windows. Or you could consider it an MDI application with child-window features.

When you plan to redesign your appIication's user interface, consider which of there models works best for your application and users. This is not a one size fits all solution but one that is customizable for your needs. With the new GUI for .NET you get access to Microsoft .NET Windows Forms, an extremely full-featured user interface solution. In Microsoft’s own words “With Windows Forms, you can create powerful Windows-based applications. You can harness the power of Windows Forms to display data, handle user input, and deploy your applications easily and with enhanced security.”

OpenEdge 10.2A coming soon

OpenEdge 10.2A is scheduled to be available soon.  OpenEdge is the only platform that is optimized for the building of Service-Oriented Business Applications.  It differentiates from other offerings in the market because:

• Its purpose to simplify building your data- and transaction- and service-centric business applications with the highest productivity
• Integration and interoperability features are built-in, thus making it easy for you to connect to any application regardless of the technology or platform its built-on
• Support of a broad and rich set of open interfaces and integrated UI capabilities to ensure your applications can be built with any UI technology you choose, and even support multiple UIs with a single set of business logic
• High performance and scalable embedded database that ensures that all your data management needs can be met

OpenEdge 10.2A focus on the commercialization of the OpenEdge GUI for .NET which provides developers with the ability to build competitive, state of the art, contemporary user interfaces for their applications using Microsoft .NET Winforms technology.   What makes OpenEdge 10.2A offering better is that developers can do so in a highly productive manner because the new functionality is built into OpenEdge, integrating in OpenEdge Architect the new development tools such as the brand new Visual Designer and the extended Class Browser, empowering you to use only ABL, the best business-purposed programming language, and being fully compatible and interoperable with your existing OpenEdge GUI, to adopt at your own pace.

No one else provides such ease of use, productivity and business functionality, all within a single purpose development environment.

But 10.2A is anticipated to have much more than the GUI for .NET!  From a host of customer-driven usability and performance enhancements in OpenEdge Architect, as well as new XML and WSDL editors, to more OO extensions including garbage collection, through a new TIMEZONE session attribute to ease the deployment and reduce the operation costs of global applications, or sparse ProDataSet XML serialization for lower resources and increased performance, or OpenEdge server products support for Windows 2008 64-bit, to mention just a few.

The very high number of members and level of participation in the 10.2A Beta program, one of our largest and exciting beta programs ever, should be a good indication of the enthusiasm and anticipation that the Progress community is showing for OpenEdge 10.2A.  So, stay tuned for more information coming soon, and hang on, just a few more weeks to go!

Salvador

* For informational purposes only. Information in this posting may not be interpreted as any commitment on behalf of Progress, and future development, timing and release of any features or functionality described remains at our sole discretion.

Business-orientation and object-orientation

With enhancements in the OpenEdge 10.1x release family, ABL (Advanced Business Language) is being extended with standard formal object-oriented (OO) functionality: objects, classes, methods, polymorphism, inheritance, delegation, statics, properties, strong typing, and more.

A big differentiator from other traditional object-oriented Languages is that ABL does not exclude other programming methodologies though: ABL is not “pure OO”, and at Progress we think that is a good thing for our customers!.   With ABL, developers can combine and integrate classes with procedures and vice versa.   As a matter of fact ABL is the only business application's development language with this capability! 

In addition, ABL’s unique and powerful built-in data awareness further differentiate it from the rest of mainstream development languages.  Again, ABL is the only business application’s development language that provides uniform and comprehensive built-in capabilities to access, manipulate and store data from different data sources and formats (including relational databases, XML, structured and unstructured files, user-defined formats, etc.) intertwining it with sophisticated business logic, making ABL particularly suited for world-class business applications.

The requirements of modern business applications for modularity, open access and reusability through disparate interfaces have never been higher. The object-oriented extensions ease the implementation of robust business applications that adhere to SOA principles, and integrate with other systems, platforms and applications --- including non-OpenEdge ones of course ---  in today’s interconnected and heterogeneous business environment, thus furthering our commitment to openness.

Where encapsulated, modular, reusable functionality is required, developers can build on the inherent capabilities provided by ABL’s formal object-orientation. Where tasks, workflows or processes are needed they can take advantage of its continued support for procedural development methodologies.

We are very excited to hear from customers using ABL object-oriented extensions (OOABL for short) reporting that they are indeed helping them simplify their Service-Oriented Business Applications, and in some cases make their code up to 40% smaller --- your mileage may vary ---, with less integration points which makes the code more uniform and easier to reuse. 

I encourage everyone to take a look at the OOABL extensions.  Even if you are not familiar with object-orientation I think you’ll be pleasantly surprised with their ease of use and you’ll be able to quickly realize development productivity benefits, and will make your applications even more robust.  And remember, you can adopt and use them at your own pace alongside or integrated with procedural methodologies.   And stay tuned, there’s much, much more to come!

Balancing relational data with an object-oriented approach to managing it

One of the major new areas in OpenEdge 10 is the language support for classes. ABL now lets you define source files as classes, as an alternative to procedures, to take advantage of many valuable object-oriented features established by languages like Java and C#, including inheritance and strong-typing of object references. One major pragmatic value of this new direction is the greater ability it gives you to define within your source code just exactly what things refer to and how different classes are related, so that the compiler can cross-check your references and give you much more feedback on your code's correctness at compile time, rather than waiting until runtime to see whether you've defined all the pieces correctly. So rather than defining a reference to a procedure as a handle variable that could point to anything at all at runtime, you define the variable as a reference to a specific class, and by gosh, the compiler will make sure that every reference to a property or method of that class is correct, and that you don't use that variable to reference anything else. This is a clear advantage to developers, and has little to do with any need for a deep understanding of object orientation.

So far, so good. But one of the major benefits of using ABL as a high-level programming language, as distinct from Java or C#, is the tight integration into the language of business logic that knows how to deal with relational data (and after all, most of the data managed by a business application written in any language is still relational), and that knows the details of the data's schema and lets you program accordingly. This is the key to the value of ABL, and goes all the way back to the language's FOR EACH Customer: DISPLAY Customer beginnings. In today's ABL we support the same kind of data manipulation, whether it's against the physical data schema (the database) or the logical schema of an application (temp-tables and ProDataSets).

This combination of support for classes with its object-oriented approach to code design, juxtaposed with the still very relational view of the business data, poses some serious challenges. Should you now try to treat each data item (a customer, say) as a true object? Does a set of all the customers in Ohio now become a collection of objects, that is, independent running instances of an ABL .r file, each holding the data for a single customer? This kind of approach has been tried in at least a few cases, and seems to go very much against the grain of the relational advantage of being able to treat these customers as an organized table of information, and presents the potential for serious performance problems as well.

There has been work in some areas on balancing the usefulness of a relational table as a way to hold and access multiple objects (like customers in Ohio), while using a more object-oriented approach to represent a single customer object, as properties of a class. See for example this thread on the PSDN Principles and OERA Forum:

http://www.psdn.com/library/thread.jspa?threadID=7645&tstart=0

There is also the question of how to balance what we traditionally describe as 'static' references to tables and fields – taking advantage of the compiler's knowledge of database and temp-table definitions – with the more dynamic approach of using a reference to a set of data (a handle, in this case) as a way to access its tables and fields and values more indirectly, using syntax like httCustomer::CustName, for instance. The static approach requires, at this stage of the product's evolution, having all the table definitions coded (perhaps as include files) in every class or procedure that references them, which is not a very encapsulated, object-oriented way of constructing things. The dynamic approach sacrifices some of the simplicity of the traditional FOR EACH...WHERE coding style along with some of the ability to count on the compiler and other tools to make sure references are correct and efficient.

So in short, we find ourselves in a transition between a more or less strictly procedural way of dealing with more or less strictly relational data, and a much more object-oriented way of dealing with what is mostly that same data. The product itself is always evolving. Future language features and other enhancements, always influenced by the experiences and the requests of our customers, help bring us closer to an ideal of really simplifying the hard job of building successful business applications. Open discussions about best practices, that is, how to do the most effective job of using what the product provides at any given point in time, are also a key component of creating a common understanding of how best to proceed.

I won't attempt any definite answers here. That would turn a blog entry into a full-blown white paper. And the point is, the answers are still in flux, and not as definite as we all would like. But the topic is important, and needs everyone’s input and experiences. There have been a number of threads on the OpenEdge Principles Forum on one aspect or another of the issues around handling relational data as objects, and you should take a look at them. To stimulate a continuing discussion, I've started a thread for comments and discussions on the subject, with this entry as a starting point. Join in. We need the participation of the broader OpenEdge community to help us guide where we go from here with the product, as well as with the discussion of how best to use it and apply its distinct and still considerable value. Here's the link to the thread, just in case you don't yet know your way around the forums:

http://www.psdn.com/library/thread.jspa?threadID=9532

Hope to hear from you.

Eclipsecon 2008

Last month, I had the pleasure of attending Eclipsecon 2008, Eclipse conference, in Santa Clara, CA. The conference was well attended with 1404 attendees representing 37 countries.  There were 10 parallel tracks and with a wide range of sessions from “Getting started” to “How to make money with Open Source”. In the past couple of years, the Eclipse ecosystem has grown rapidly with 11 top level projects that cover many of the areas of SDLC tooling. With the recent announcement of the Runtime (RT) project, they now have a significant traction on Rich UI client (using RCP technology), Rich Web UI (using RAP technology) and the application server areas with OSGi and “Server Side OSGi” projects. 

The conference in general had a lot of buzz about web as a platform for Eclipse and AJAX tooling. I have attended Eclipsecon for the past three years and the previous conferences have been very technical with lot of sessions on “how to” in Eclipse where they would get into code within the first 10 min of the session. But I noticed a slight change in focus this year – there were a lot of success stories, reference implementations, adoption related sessions and many business focused sessions like “How to make money from open source”. In my opinion this change somewhat reflects the maturity process for the Eclipse ecosystem.

You can browse thru’ the conference materials at http://www.eclipsecon.org/2008. Happy reading!

So in summary, Eclipse has gained significant momentum and looking at the future direction of where Eclipse tooling is headed further strengthens OpenEdge Architect strategy of providing an open and productive tooling platform for OpenEdge customer base. The continued growth of Eclipse ecosystem will continue to enable OpenEdge customers to take advantage of the Eclipse platform and ecosystem.

One of the goals for OpenEdge Architect is to make OpenEdge n-tier business application development iterative and more productive. Looking at the different Eclipse projects, there seem to be definite synergies between Eclipse projects like Web Tools Project (WTP) for providing AppServer and Webspeed tooling support, Mylyn and the need for task based development environment, Dynamic language toolkit (DLTK) makes it relatively easy to add more editors feature quickly, Data tools project (DTP) for database schema navigation etc…. So we are looking to further prototype and explore of some of these Eclipse projects to meet OpenEdge customer needs.

Following is a brief summary of some of the sessions that I thought were interesting - more details about this can be found in the conference material on the link above.

1. Eclipse 4.0 (e4) – There was a lot of discussion about the next generation of Eclipse tools – Eclipse 4.0 (e4). E4 is expected to ship in June 2010 with a prototype ready by June 2009. Web as another platform for Eclipse and SWT was one of the main themes for Eclipse 4.0 platform team. The platform team had a few cool prototypes and demo on possibilities. Eclipse committee seems to be still undecided on the definite direction on how Eclipse will be available on Web. Some of the AJAX solutions that were being considered included RAP, GWT, DOJO library with Java compiled to JavaScript, Flex and Action Script, Silver Light etc…

2. Rich AJAXPlatform (RAP) – RAP technology is very promising and provides Rich UI on Web for applications that are built for desktop. The RAP platform takes an application that is built using RCP (Rich Client platform) and renders it on the Web – without many changes to the application source code – single source multiple platforms. RAP dynamically exchanges SWT widgets with RWT widgets that work in client-server distributed mode.  Branding for the RAP based web UI provided by Themes.

3. Eclipse Dynamic Languages Toolkit (DLTK) – Very promising technology for adding new editor features to IDE’s. The DLTK relies on a standard “Structure Model” to provide functionality like outline view, search, open type, open declaration, documentation access, code completion. Internally DLTK has a selection engine that provides a lot of capabilities mentioned above.

4. Mylyn – The task based development paradigm promoted by Mylyn has lot of traction and I heard lot of developers starting to use it. The Eclipse 3.4 release seems to further add more stability and extensibility and a host of other SCM (software configuration management) tools are integrating their solutions with Mylyn.

5. Data Tools Project (DTP) – DTP functionality keeps getting better and better – they provide Data source configuration, navigation, SQL  editor, SQL query builder etc... DTP’s real value is in its integration with other projects in the Eclipse ecosystem – like BIRT which makes the story very compelling.

6. Security in Eclipse 3.4 – The security improvements in Eclipse 3.4 are significant. Trusted bundles, ability to encrypt sensitive data in Eclipse workspace and Certificate store in RCP world are some of the enhancements to the Eclipse 3.4 release.

7. JMaki – This open source client-server AJAX framework is mainly driven by Sun and the Glassfish guys and conforms to Open AJAX standards. I was very impressed with the demo and it appeared to be very easy to build Mash-ups. This has Eclipse integration. This framework makes it easy to use most other AJAX toolkits (DOJO, etc…) and it acts as a standardized layer below the AJAX toolkits. More details at http://jmaki.com

About That Scalability ...

Does scalability only apply to very large deployments ?

Try this, fold a piece of paper in half by bringing the top edge down to meet the bottom edge. Now imagine an OpenEdge application with a 20GB database that uses either wifi or cabled network to run a small business. Imagine the business system occupies that half-sheet of paper, uses 2 watts of power, weighs two pounds, and costs $400 US.

That's reality today. I bought one of those little Eee laptops recently, and was delighted at how easy the linux system is to use, and how easy it integrates with my Windows-dominated infrastructure. Nice job. Linux even runs my spreadsheets and presentations unchanged (you can even change the laptop to XP if you want). What a nice parallel this "mini-system flexibility" is to OpenEdge! The ability to scale down is partly one of architecture and partly discipline in the implementation.

But why scale down? One reason could be new products or new markets. Another reason is to focus on providing a consistent service at a high performance level. Have you seen applications that have just seemed to grow and grow. Application bloat leads to a loss of control over the key function of the software, and it seems that poor usability and uneven performance come right along for the ride. So maybe scaling down is another way at looking for clear boundaries between layers of an application as well as separation of functions in an application environment. That highly connectable 2 pound workstation was no accident! It was drawn from the OLPC (One Laptop Per Child) design effort which is spawning a lot of creativity in the Ultra-Mobile PC market. A solid software architecture has some similarities in terms of defined interfaces, guiding principles, and scalable design.

Does your application scale up? Or down? Or out? Sometimes a "readiness review" of your architecture from scalability or an service-oriented view can lead to a plan that leads into the business roadmap by opening up new options. We hope that the new capabilities in OpenEdge ABL can help you implement that roadmap in a smooth way that phases in the stages you plan for your evolution. Are you trying this approach? How well is this  working for you? The AutoEdge application gives some nice examples of how the ABL supports the scalable OpenEdge Reference Architecture. I was just reviewing a presentation about AutoEdge that will be done for Exchange in Paris. If you are attending, this session could be very useful. Another interesting session shows a racetrack example which illustrates how a SOA environment comes together with Sonic, OpenEdge, and other fine products. Check them out and let me know what you think.

What about Deployment?

From the deployment side we still support efficient storage of data, so that 20GB database on the tiny laptop might hold a surprising amount of business data. we still support compatibility of the database from the little laptop up through large systems too. With OpenEdge 10.1B, every database can grow to have very large tables, wide indexes, and a full range of datatypes. You even get built-in management features like automatic defragging now. On a small database, it is easy to make it run "hands off". For large databases, you get on-line management of table space, schema additions, and the ability to increase some key performance parameters without taking downtime. OpenEdge needs less tuning than those big databases, and we are still the #1 pure-play database for applications that need a capable database "built right in". Our vision is to let your production environment evolve smoothly with a self-tuning, self-healing, and self-provisioning database that handles the transactional business load. What else? Well, improvements in appservers keep coming, as do improvements in the reporting capabilities of OpenEdge SQL. Similarly, support for Sonic keeps getting easier with 10.1C, and we'll talk about that in a separate note. We do take performance and manageability seriously, and the roadmap for this area really features a lot of customer-requested capabilities. We really appreciate your advice and insights into your needs. Please keep them coming! What are your top 5 needs in the database and appserver area?

Whatever happens in the scalability area, one thing remains. Scalability is not about standing still. It's about a dynamic range and that means opportunity for you and for us. Together.

Of OpenEdge, Toasters and Vacuum Cleaners

Are toasters and vacuum cleaners ultimate examples of commodities? Of course!, right? Well, think again.

A few months back I read ‘The Myth of Commoditization’ by Michael Schrage, an article in the ‘MIT Sloan Management Review’ magazine and ever since I find myself getting back to the facts and the concepts masterfully described by Mr. Schrage in his two-page article.

By know, I hope that you’re a little intrigued and you will want to read on this, my first, OpenEdge Perspectives blog. There are many aspects of what Progress Software has done with OpenEdge over the years that in my opinion share parallelisms with Toasters and Vacuum Cleaners not being commodities: Quite the contrary, retaining and extending our, as their’s intrinsic and perceived value. Progress (the product and the company shared the name back then) was first released in the early 1980s and throughout 25 years of innovation cycles driven by our customers (Thank you!), the market and the IT industry we have kept our mission: “Simplify the job of building the world’s best business applications”.

How many evolutions and revolutions!: From the minis, hosts, personal computers, client-server, application servers, to the Internet. From character, GUI, one-tier, two-tier to global all-tier. From procedural, event-driven, object-oriented to SOA and software-as-services. How many opportunities to become commodity! And nevertheless Progress is not.

As information technologies evolved, the more the unfulfilled promises from many for simple, easy to use offerings to build long-lasting and ever-changing business applications. Simplify is difficult!. First you need to make something possible. Many products stop there. Then you can simplify. Very few actually do.

Let me tell you a story: Long ago, when I was a programmer using Progress and working on-site, one of the company’s line of business manager said to me: ‘You see, I’ve been looking for a while at what you do and no matter what I ask you to do, or how complex my request may be, you always, always do the same thing: You start a tool that I noticed is called Procedure Editor. Then you type a few lines of code which for the most I can actually understand and voilà you have the information I needed. Quite often in a format that is not pretty I have to say, but boy you are fast!’

That company had Progress-based applications, and a bunch of other ones they had purchased, acquired or developed over the years. All in all a hodge-podge of C-ISAM and an early Oracle database, COBOL, BASIC and some C, and an IBM mainframe with RPG of course. We had installed Progress and the Oracle and C-ISAM DataServers (back then Progress called them Gateways). Many of the ad-hoc requests I was getting from LOB managers meant to cross-reference and join information from many of theses systems, and yes, I always started with the Procedure Editor, connecting to the data sources, looking at their schemas (nevermind some were not even relational), and writing a few lines of ABL. Such was the power of Progress.

Many customers tell me that today they are doing similar things with OpenEdge Architect with IntelliSense, auto-completion, dragging-and-dropping from database schemas to the code editor and the works compared to my character-based Procedure Editor. Perhaps some of them even have to gather information from web services. What’s the drill? Get and look at the WSDL, connect, and RUN, where I used to connect to Progress, Oracle and C-ISAM, check the schemas and RUN.

So what’s the moral? Our customers tell me that Progress OpenEdge’s unique, intrinsic and sustained value to them is its business focus. If we managed to simplify building complex business applications including reading, writing, and managing data from displarate data sources, now we are simplifying to build, extend and integrate heterogeneous business applications using messaging, Enterprise Service Bus, Web services, and SOA-principles with OpenEdge, .NET, Java and standard interfaces.

Progress cannot just make things Simple, because businesses are not.  We make things Simpler! As for Toasters and Vaccuum Cleaners, commoditization is a misleading guide to innovation, a race to the bottom. At Progress Software we prefer races to the top. In the long run, everything is not a toaster. Not even toasters.