Marionette Application instances are kind of like layout views. You can give them regions, and use these regions to show smaller views. There's one important difference, between a layout view an an application. With the latter, there's generally only one. Layout views on the other hand, generally exist in larger numbers. Another difference is with where they get their markup from. The application works with that's already in the DOM while a layout view works with a template that it renders.
Showing posts with label application. Show all posts
Showing posts with label application. Show all posts
Monday, December 15, 2014
Marionette: Layout Views For Applications
Monday, February 25, 2013
The Web Shaped By Applications
The web used to be composed of simple pages. It still is, to a degree, but less and less so. For example, Wikipedia is the active giant still spewing forth pages rich with information. There are plenty of news sites, and blogs just like this one that I wouldn't consider applications. But less and less so. Instead, we're craving the interactivity brought about by applications. The information is still there, just arranged, and curated differently. Instead of a monolithic blob, such as this post, the pieces of information are fragmentary. Not necessarily incomplete, but defined by a work-flow different from what we're used to. Will there be a need for pages in the future when the web is composed of powerful applications that allow us to better carve out the chunks we need at that moment?
Thursday, October 18, 2012
Cloud Application Support
Consumers of the cloud are of only a few variety. Maybe even two. There are those who really enjoy configuring the low-level platform aspects of what they're deploying. To these consumers, CPU topology matters, as do the network card specifics, and whether or not ACPI features are available. Platform level concerns are of the utmost importance in any environment — cloud or no cloud. But if we treat the supporting platform as the only critical piece of the system, we wouldn't succeed in our mission. Which brings me to my second class of cloud consumer — the application developer. The easy solution, and one that I think we're relying on a little too much today, is don't treat the application as an actor in the cloud landscape. Instead, the established approach is to treat the applications that actually fulfil business requirements as something that gets put into a platform container. The container is a cloud-friendly wrapper that encapsulates the application to a point where it doesn't know it is virtual.
Wednesday, June 16, 2010
Configuration Design
How much thought goes into what your configuration file will look like when developing an application? That is, does the overall configuration structure have an impact on the quality of your finished product? This question can be asked from more than one perspective. For instance, from the end user's point of view, is the set of potential configuration options cohesive and easy to understand? The number of potential configuration options also plays a role in the overall manageability of the application because more configuration options means more complexity. This same point needs to be considered from the application's point of view. Adding flexibility by means of configurable options has an impact on your application's design. Making any aspect of your application configurable adds variability to something that could have been constant, or hard-coded. Beyond the size and structure of an application configuration, there is meaning behind each configuration option. Thinking about what each configuration option means before adding it to the configuration design is important. Lets take a look at an example of how we might go about designing a configuration schema for a simple system.
The system under development is a simple desktop GUI application data viewer. The application will support two data formats; JSON and XML. The GUI for this application is fairly straightforward in that it will have two tabs. These tabs will offer the end user a different view of the data. The first tab will use a tree widget to display a hierarchical view of the data. The second tab will use a table or grid widget to display the data. In the latter tab, clicking a row will reload the table or grid with that row's data if it can be displayed as a table or grid. Otherwise, a dialog is opened to display the details of the row data. Likewise, if a leaf node in the tree widget of the first tab is selected, the same dialog will appear. The application can load the data from a local file or from a URI on the web.
This intentionally simplistic system hardly justifies the need for having a configuration. It is ideal, however, for our purposes here because we want to elaborate on how the configuration values for the application come into being. Lets start by looking at the static aspects of our sample application. By static, I mean aspects of the application that remain constant throughout it's lifetime. These aspects aren't configurable. It is worth looking at the fundamental features that will not change before designing configurable elements. This way, we can eliminate candidates from our list of potential configuration values. Looking at the sample application under development, there are two supported data formats, JSON and XML. One potential configuration value we could add is a list of supported data formats. Logically, we would want to have the ability to extend our application to support more than just JSON and XML formats. However, in our case, this is something that will remain constant. The system is a JSON/XML reader so we don't want to change the what the application does best.
Now that we've eliminated a potential configuration option, lets think about some configuration categories, or sections. Configuration sections are a group of related configuration options. For instance, in our application, we would probably want a configuration section for GUI settings. The benefit to having configuration options grouped by sections is that the end user can get a better handle on what they're changing. Conceptually, sections, or categories, give the end user a little more confidence when manipulating the configuration. For instance, if a user sees a GUI section in the configuration file, they're going to feel at ease changing these options. This is because the intent of this particular group of options is clearly stated; change these values to alter the look and feel of the GUI. Additionally, from the developer's perspective, configuration sections give us an opportunity to map configuration options to concepts found in our code. GUI configuration options might map to only a handful of classes, or possibly a single base class.
Since our sample JSON/XML reader application is so simplistic, we're limited in the number of configuration sections we can create. Our application is a desktop GUI application so "gui" is a good candidate configuration section. We can also read JSON or XML from the web so "network" might be considered for a configuration section. Finally, we may also want a "core" section for configuration options that don't fit into either of the above sections. The "core" configuration section is intentionally general because we still need to leave room for changes. As our application code evolves and is re-factored, we may discover new concepts to map our configuration options to. The "gui" and "network" concepts, although broad, are clear enough for both users and developers upfront.
Lets take a step back from our sample application for a moment and take a look at some the various types of configuration options. The most basic type of configuration option we can have is a boolean, on/off value. These are the configuration options that either enable or disable some aspect of the system. With boolean configuration options, you typically specify a true value to enable something. For instance, setting "ssh_enabled" to a true value enables SSH. We can also use boolean configuration options to negate a certain aspect of the system. For instance, setting "ssh_disabled" to a true value disables SSH. In the latter case, we've changed the meaning the boolean configuration option to take on a negative meaning. Most of the time, the former approach of true values acting as an enabler works best because the intent is always clear. Configuration options can also specify a literal value such as a string or integer. These types of configuration values are useful for default values used in the system. Configuration options can also specify a list of literal values are also typically used as defaults within the system or as a means to extend the system.
Going back to our JSON/XML example, lets come up with some configuration values. Is there any aspect of the application we may like to disable at some point? Perhaps the obvious choice is to have the ability to disable the JSON format or to disable the XML format. What type of configuration option should we use to accomplish this? Two boolean configuration options, "json_enabled" and "xml_enabled", could be added to the configuration file. By default, our application would probably have these two options set to true since these options make up the core of the system. Next, what configuration section do these configuration options belong to? For now, they go in the "core" section because changing these options has an impact on several concepts in our application. If we were to set "xml_enabled" to false, the XML tab would no longer be displayed. An alternative to using boolean configuration options is a list. For instance, we could define a "data_formats" configuration option that defaults to a list of "JSON" and "XML". With this approach, there is a need for only a single configuration option instead of two. But, the problem with this approach is that we've introduced a notion of extensibility to both developers and the end user when this isn't the case. To disable one of these data formats, we'd have to remove it from the list. Once removed, it is as though the data format never existed.
What about our other two configuration sections, "network" and "gui"? In the network section we have a good opportunity to use a list configuration type. An "allowed_hosts" option would allow us to specify a list of hosts in which the end user is allowed to request data from. The "network" section could also use a "network_enabled" boolean option that allows us to disable networking entirely. Our "gui" configuration section is largely undefined at the moment. This is fine because the last thing we want to do is throw configuration options into sections when they aren't needed. The "gui" section is a good place to put proxy configuration options, if and when they are needed. Our application is going to use a GUI library of some sort and these libraries offer a plethora of parameters to change the look and feel of the application. The configuration options defined in the "gui" section can usually be passed directly through the application and into the GUI library.
What we have seen here with our simple example is that there is some thought involved with how a finished configuration file for an application should look. The options used in your configuration file should map well to the concepts found in your application design. If you're writing an application and something seems unclear about a configuration option, change it. But don't hesitate as the sooner you correct this ambiguity the better. Problems with configuration options may be badly named options or they may have misused values. These issues sometimes aren't trivial to spot but putting yourself in the mindset of someone who has to use your configuration file for productive work will often help with the design.
The system under development is a simple desktop GUI application data viewer. The application will support two data formats; JSON and XML. The GUI for this application is fairly straightforward in that it will have two tabs. These tabs will offer the end user a different view of the data. The first tab will use a tree widget to display a hierarchical view of the data. The second tab will use a table or grid widget to display the data. In the latter tab, clicking a row will reload the table or grid with that row's data if it can be displayed as a table or grid. Otherwise, a dialog is opened to display the details of the row data. Likewise, if a leaf node in the tree widget of the first tab is selected, the same dialog will appear. The application can load the data from a local file or from a URI on the web.
This intentionally simplistic system hardly justifies the need for having a configuration. It is ideal, however, for our purposes here because we want to elaborate on how the configuration values for the application come into being. Lets start by looking at the static aspects of our sample application. By static, I mean aspects of the application that remain constant throughout it's lifetime. These aspects aren't configurable. It is worth looking at the fundamental features that will not change before designing configurable elements. This way, we can eliminate candidates from our list of potential configuration values. Looking at the sample application under development, there are two supported data formats, JSON and XML. One potential configuration value we could add is a list of supported data formats. Logically, we would want to have the ability to extend our application to support more than just JSON and XML formats. However, in our case, this is something that will remain constant. The system is a JSON/XML reader so we don't want to change the what the application does best.
Now that we've eliminated a potential configuration option, lets think about some configuration categories, or sections. Configuration sections are a group of related configuration options. For instance, in our application, we would probably want a configuration section for GUI settings. The benefit to having configuration options grouped by sections is that the end user can get a better handle on what they're changing. Conceptually, sections, or categories, give the end user a little more confidence when manipulating the configuration. For instance, if a user sees a GUI section in the configuration file, they're going to feel at ease changing these options. This is because the intent of this particular group of options is clearly stated; change these values to alter the look and feel of the GUI. Additionally, from the developer's perspective, configuration sections give us an opportunity to map configuration options to concepts found in our code. GUI configuration options might map to only a handful of classes, or possibly a single base class.
Since our sample JSON/XML reader application is so simplistic, we're limited in the number of configuration sections we can create. Our application is a desktop GUI application so "gui" is a good candidate configuration section. We can also read JSON or XML from the web so "network" might be considered for a configuration section. Finally, we may also want a "core" section for configuration options that don't fit into either of the above sections. The "core" configuration section is intentionally general because we still need to leave room for changes. As our application code evolves and is re-factored, we may discover new concepts to map our configuration options to. The "gui" and "network" concepts, although broad, are clear enough for both users and developers upfront.
Lets take a step back from our sample application for a moment and take a look at some the various types of configuration options. The most basic type of configuration option we can have is a boolean, on/off value. These are the configuration options that either enable or disable some aspect of the system. With boolean configuration options, you typically specify a true value to enable something. For instance, setting "ssh_enabled" to a true value enables SSH. We can also use boolean configuration options to negate a certain aspect of the system. For instance, setting "ssh_disabled" to a true value disables SSH. In the latter case, we've changed the meaning the boolean configuration option to take on a negative meaning. Most of the time, the former approach of true values acting as an enabler works best because the intent is always clear. Configuration options can also specify a literal value such as a string or integer. These types of configuration values are useful for default values used in the system. Configuration options can also specify a list of literal values are also typically used as defaults within the system or as a means to extend the system.
Going back to our JSON/XML example, lets come up with some configuration values. Is there any aspect of the application we may like to disable at some point? Perhaps the obvious choice is to have the ability to disable the JSON format or to disable the XML format. What type of configuration option should we use to accomplish this? Two boolean configuration options, "json_enabled" and "xml_enabled", could be added to the configuration file. By default, our application would probably have these two options set to true since these options make up the core of the system. Next, what configuration section do these configuration options belong to? For now, they go in the "core" section because changing these options has an impact on several concepts in our application. If we were to set "xml_enabled" to false, the XML tab would no longer be displayed. An alternative to using boolean configuration options is a list. For instance, we could define a "data_formats" configuration option that defaults to a list of "JSON" and "XML". With this approach, there is a need for only a single configuration option instead of two. But, the problem with this approach is that we've introduced a notion of extensibility to both developers and the end user when this isn't the case. To disable one of these data formats, we'd have to remove it from the list. Once removed, it is as though the data format never existed.
What about our other two configuration sections, "network" and "gui"? In the network section we have a good opportunity to use a list configuration type. An "allowed_hosts" option would allow us to specify a list of hosts in which the end user is allowed to request data from. The "network" section could also use a "network_enabled" boolean option that allows us to disable networking entirely. Our "gui" configuration section is largely undefined at the moment. This is fine because the last thing we want to do is throw configuration options into sections when they aren't needed. The "gui" section is a good place to put proxy configuration options, if and when they are needed. Our application is going to use a GUI library of some sort and these libraries offer a plethora of parameters to change the look and feel of the application. The configuration options defined in the "gui" section can usually be passed directly through the application and into the GUI library.
What we have seen here with our simple example is that there is some thought involved with how a finished configuration file for an application should look. The options used in your configuration file should map well to the concepts found in your application design. If you're writing an application and something seems unclear about a configuration option, change it. But don't hesitate as the sooner you correct this ambiguity the better. Problems with configuration options may be badly named options or they may have misused values. These issues sometimes aren't trivial to spot but putting yourself in the mindset of someone who has to use your configuration file for productive work will often help with the design.
Monday, April 5, 2010
Hashing URIs
Clients of URIs often need to specify some sort of client parameter that is returned as part of the HTTP response. This parameter is intended to preserve the application state by encoding it into the URI.
A common practice is instead of passing the client state as a GET HTTP parameter, to provide the client state as a hashed URI segment. This segment would represent the client state. It is a preferable URI practice because the application state is still encoded as part of the resource URI but doesn't need to be sent to the server.
One aspect of this practice to be weary of is mistaking application state for resources. If the intent is to use the application state as the hashed URI segment, only use it for application states and not data resources.
A common practice is instead of passing the client state as a GET HTTP parameter, to provide the client state as a hashed URI segment. This segment would represent the client state. It is a preferable URI practice because the application state is still encoded as part of the resource URI but doesn't need to be sent to the server.
One aspect of this practice to be weary of is mistaking application state for resources. If the intent is to use the application state as the hashed URI segment, only use it for application states and not data resources.
Application Portability
In this entry, we see an impressive example of application portability. The application runs on several platforms without any modifications to the code base. Portability is huge these days with the number of mobile devices on the market. How what is the best way to achieve optimal portability? Should this be the responsibility of the application or the platform on which it runs?
Interpreted programming languages like Java and Python attempt to solve the portability problem by producing hardware-independent byte code. This byte code is then executed by a executable interpreter. Here, it is the interpreter's responsibility to maintain portability. And they do a good job for the most part. But applications still aren't aren't fully platform agnostic.
So if all this hard work is done by the interpreter for dynamic programming languages, how do we achieve platform portability with compiled languages such as C++? Here we can use libraries that help developers with platform independence. For instance, Qt is a largely platform independent library. With compiled languages you have more control but the trade-off is that much more complexity is necessary for these applications to run on more than one platform. At least with the same code base.
Interpreted programming languages like Java and Python attempt to solve the portability problem by producing hardware-independent byte code. This byte code is then executed by a executable interpreter. Here, it is the interpreter's responsibility to maintain portability. And they do a good job for the most part. But applications still aren't aren't fully platform agnostic.
So if all this hard work is done by the interpreter for dynamic programming languages, how do we achieve platform portability with compiled languages such as C++? Here we can use libraries that help developers with platform independence. For instance, Qt is a largely platform independent library. With compiled languages you have more control but the trade-off is that much more complexity is necessary for these applications to run on more than one platform. At least with the same code base.
Saturday, March 20, 2010
Reinventing The Standard
Lets face it. If you want to write code today, you are going to have to understand and interact with one or more standards. Probably more. Standards can more often than not be viewed as a necessary evil. Well, standards aren't evil, they just seem that way because they are quite good at pointing out human error.
As an example, if you are putting together even a simple networked application, it makes sense to use some kind of application-level data transfer standard such as HTTP. Even if it is a simple application, the development effort isn't likely to move any faster by using non-standardized protocols.
Sometimes it does make sense to reinvent standards. All the developers in the world are never going to agree on what the standard programming language that everyone should use. Not going to happen. There are too many cases where one is better than the other. This is fine because we don't need to standardize programming languages. The protocols and data representations are all that really matter.
This also means that any developer isn't restricted to using a popular library API. If it doesn't fit in well with what they are trying to do, it isn't worth it. The code saved from being written by using the library could cause more harm than good. This shouldn't matter as long as the publicly accessible components of the application use well understood standards.
As an example, if you are putting together even a simple networked application, it makes sense to use some kind of application-level data transfer standard such as HTTP. Even if it is a simple application, the development effort isn't likely to move any faster by using non-standardized protocols.
Sometimes it does make sense to reinvent standards. All the developers in the world are never going to agree on what the standard programming language that everyone should use. Not going to happen. There are too many cases where one is better than the other. This is fine because we don't need to standardize programming languages. The protocols and data representations are all that really matter.
This also means that any developer isn't restricted to using a popular library API. If it doesn't fit in well with what they are trying to do, it isn't worth it. The code saved from being written by using the library could cause more harm than good. This shouldn't matter as long as the publicly accessible components of the application use well understood standards.
Thursday, March 11, 2010
Handling Callback Variables
With Javascript applications that make asynchronous Ajax requests, does it make sense to store a global variable that indicates the callback that should be executed? That is, depending on the current state of the application, a different callback function may need to execute for the same API call. Should a global variable be set before the request is made and checked each time by the response?
That doesn't feel right to me. Neither does sending application data along with the API request just to be used by the callback. That would mean sending application state to the server which isn't a good thing as far as I'm concerned.
I like the idea of listening for certain events that the callback might emit during execution. The callback might emit a certain type of event each time it is run. The events are always emitted but the application may not always be listening. When the application is in a certain state, it will be listening. The handlers of these events could be considered secondary callbacks.
That doesn't feel right to me. Neither does sending application data along with the API request just to be used by the callback. That would mean sending application state to the server which isn't a good thing as far as I'm concerned.
I like the idea of listening for certain events that the callback might emit during execution. The callback might emit a certain type of event each time it is run. The events are always emitted but the application may not always be listening. When the application is in a certain state, it will be listening. The handlers of these events could be considered secondary callbacks.
Tuesday, October 20, 2009
Twisted Application Reactors
At the heart of any Twisted Python application lies one or more reactors. Reactors, as the name suggests, react to events. Whether the event is local or remote, the reactor is the core concept in Twisted concerned with invoking behavior in response to these events.
The Twisted application module defines an application Reactor class. This class is extended by actual reactor implementations that may be used within Twisted applications. Reactors that are available for installation may be enumerated over by using the getReactorTypes() function. The use of this function is illustrated below.The design of the Reactor class is really straightforward. The Reactor is an extensibility mechanism of the Twisted framework. That is, it can be installed and used as necessary. The Reactor class provides the IPlugin and the IReactorInstaller interfaces. The Reactor class and the interfaces it provides are illustrated below.
The getReactorTypes() is useful for providing choices to the user. This would actually make more sense as a configuration option for advanced users such as an administrator.
The Twisted application module defines an application Reactor class. This class is extended by actual reactor implementations that may be used within Twisted applications. Reactors that are available for installation may be enumerated over by using the getReactorTypes() function. The use of this function is illustrated below.
#Example; Enumerating reactor types.
#Import the required function.
from twisted.application.reactors import getReactorTypes
#Main.
if __name__=="__main__":
#Iterate over the reactor types.
for i in getReactorTypes():
#Display reactor information.
print i.shortName
print i.description,"\n"
The getReactorTypes() is useful for providing choices to the user. This would actually make more sense as a configuration option for advanced users such as an administrator.
Tuesday, October 6, 2009
Palm And Open Source
An interesting read over at IT wire about how Palm is apparently turning down applications built to run on its' platform from appearing in its' application catalog. There is nothing inherently wrong with this as they have a right to do so. The strange thing is that the rejected applications included an open source license.
If nothing else, this shows that there is still a bias against the fact that open source applications are not unique to specific vendors. That is, users can go out and get these applications, even modify and rebuild them, all on there own. Why this scares companies so much baffles me to no end. Especially given the huge momentum the open source movement has been gaining over the past few years.
If nothing else, this shows that there is still a bias against the fact that open source applications are not unique to specific vendors. That is, users can go out and get these applications, even modify and rebuild them, all on there own. Why this scares companies so much baffles me to no end. Especially given the huge momentum the open source movement has been gaining over the past few years.
Tuesday, April 28, 2009
Exploring Application Menu Data Structures
All modern GUI applications have menus in one form or another. These menus offer the end user an easy way to navigate throughout the application while consuming minimal real estate. This is achieved because menus in applications are often hierarchical, which means that only the top level of the hierarchy needs to be displayed when the menu is not being navigated. Not only do menus help make efficient use of the application GUI space, but they also help with the logical organization of the actions the user may perform within the application. As the user navigates to lower levels in the hierarchy, the more specific the available actions become. Horizontal, desktop-like menus are becoming more frequent in web browser GUI applications. This further complicates the task of designing a portable menu data structure.
The hierarchical menu data structure is by far the most commonly encountered menu structure. The data structure for GUI menus changes drastically when the structure is built dynamically verses a static menu structure. For statically built menus, which are represented by HTML, there is no concern about changing menu items. Although this approach is a poor design, the developer simply edits the HTML menu structure to add in the new menu items as needed. With static menus such as these, the structure is entirely dictated by the surrounding page and CSS styles. Another reason for avoiding static menu data structures. Consider the requirement of dynamically building a menu data structure that is functional for both hierarchical and non-hierarchical menu styles. If the data structure used for this is dynamically constructed, it can be reused. If we want to use this dynamic menu-building code to construct a single-level GUI menu, we simply use the code to build hierarchy data structure with multiple roots an no children. However, this calls for flexible presentation code which transforms the data structure into the GUI. This is another challenging problem in its' own right.
Here is an example data structure that could potentially be used to build a GUI menu.
Here, we have two root elements in the hierarchy. Here is another example of representing the same menu data structure.
Here, children are explicitly specified for each node in the hierarchy. Both approaches are valid ones, one preferred by one developer over the other. However, the boss of what this data structure should look like, ultimately, is the code that uses it to build the GUI menu.
The chief idea behind using data structures such as these, and building them dynamically, is to achieve better portability and reuse with GUI code. However, much GUI code, especially in web applications, change the menu data structure simply to change the style of the GUI. This is invalid since the menu items do not change. It would be much nicer, for developers hailing from all walks of life, if a consistent GUI menu data structure could be used and reused. This is especially important for cross-browser compatibility in web applications. The good news is that many modern javascript toolkits support the notion of widgets. The widgets within these widget sets comply with one another to offer a consistent style framework. This gives developers an opportunity to use a consistent menu data structure. Widgets aren't always needed for this purpose. If developers write their own code to build the intermediary HTML representation of the menu data structure, that works too. Just be consistent about it.
The hierarchical menu data structure is by far the most commonly encountered menu structure. The data structure for GUI menus changes drastically when the structure is built dynamically verses a static menu structure. For statically built menus, which are represented by HTML, there is no concern about changing menu items. Although this approach is a poor design, the developer simply edits the HTML menu structure to add in the new menu items as needed. With static menus such as these, the structure is entirely dictated by the surrounding page and CSS styles. Another reason for avoiding static menu data structures. Consider the requirement of dynamically building a menu data structure that is functional for both hierarchical and non-hierarchical menu styles. If the data structure used for this is dynamically constructed, it can be reused. If we want to use this dynamic menu-building code to construct a single-level GUI menu, we simply use the code to build hierarchy data structure with multiple roots an no children. However, this calls for flexible presentation code which transforms the data structure into the GUI. This is another challenging problem in its' own right.
Here is an example data structure that could potentially be used to build a GUI menu.
{\
"File":[{"Exit":{"action":exit()}}],\
"Edit":[{"Heading":[{"H1":{action:h1()}},\
{"H2":{"action":h2()}}]\
}]\
}
[
{"title":"File",\
"children":[{"title":"Exit",\
"action":exit()}]},\
{"title":"Edit",\
"children":[{"title":"Heading",\
"children":[{"title":"H1",\
"action":h1()},\
{"title":"H2",\
"action":h2()}]\
}]\
}\
]
The chief idea behind using data structures such as these, and building them dynamically, is to achieve better portability and reuse with GUI code. However, much GUI code, especially in web applications, change the menu data structure simply to change the style of the GUI. This is invalid since the menu items do not change. It would be much nicer, for developers hailing from all walks of life, if a consistent GUI menu data structure could be used and reused. This is especially important for cross-browser compatibility in web applications. The good news is that many modern javascript toolkits support the notion of widgets. The widgets within these widget sets comply with one another to offer a consistent style framework. This gives developers an opportunity to use a consistent menu data structure. Widgets aren't always needed for this purpose. If developers write their own code to build the intermediary HTML representation of the menu data structure, that works too. Just be consistent about it.
Subscribe to:
Posts
(
Atom
)