You will be redirected in 30 seconds or close now.

ColdFusion Authors: Yakov Fain, Jeremy Geelan, Maureen O'Gara, Nancy Y. Nee, Tad Anderson

Related Topics: ColdFusion

ColdFusion: Article

Streamlining Data Entry Applications

Streamlining Data Entry Applications

You may not believe this, but you'll probably spend more time maintaining your ColdFusion application once it goes into production than you spent developing it in the first place. Among IT professionals it's well known that the effort required to support applications over time is significantly larger than the effort required to build them. Applications are like children: the effort and dollars required to bring them into the world are sizable, but once they're here you'll support them for years. Thus it behooves you to take measures to minimize the effort required to maintain your applications. But how do you do this? One of the most effective solutions is to develop standard techniques and approaches for handling similar problems.

This article presents a compelling, reusable framework for data entry applications. In relational database applications, data entry applications usually involve mechanisms for reviewing, creating, editing and deleting records in tables, so that's what our framework will support. You will, of course, find situations in which this framework needs to be altered somewhat because your requirements are unusual. In many situations, however, this framework is entirely workable.

Data Entry Framework
First, let's look at the framework (see Figure 1). The basic idea is simple: five templates are used to create an application. You create new versions of four of the templates for each data entry app, but you use the same techniques from one application to the next. One template, the Delete prompt (DeletePrompt.cfm in our examples), is reused, as is, in each of your data entry applications. I prefer to name my templates like this:

  • AppNameList.cfm
  • AppNameForm.cfm
  • AppNamePost.cfm
  • AppNameDel.cfm

    AppName is replaced by the name of the data entry application, e.g., MaintainOrdersList.cfm, MaintainOrdersForm.cfm, MaintainOrdersPost.cfm, etc. The templates always call each other and are related to each other the same way.

    As shown in Figure 1, each of the five templates plays the same role in every data entry application. The list template, for example, is always responsible for presenting a tabular listing of records of a particular type. It is always responsible for calling your form template and your delete template. The form template, for example, allows users to add or edit individual records and will always call your post template. As each template always provides the same function, by following these naming conventions, your application will become easier to maintain because you'll be able to tell instantly what each template is responsible for.

    Last July I spoke at the ColdFusion User's Conference in Fort Collins, Colorado. One attendee suggested that the logical extension of my approach is to put everything in one template. I can't recommend this idea, based on tenets of structured programming. The notion is that each module (or in the case of ColdFusion, each template) should be focused on providing one function. When a module performs too many functions (e.g., listing, adding, editing, deleting, saving), its internal logic becomes convoluted and difficult to follow. From the perspective of making applications easy to maintain, there is no benefit to using one template to do everything.

    One Form for Adding and Editing
    New CF users usually develop one form for creating new records and a separate form for editing records. This makes your application harder to maintain. Why? Because whenever there's a change to some aspect of your data entry field, you'll need to change it in two places - the add and edit templates. The more places you have to fix something, the more likely it is you'll make a mistake. In my framework I need only one template for adding and editing. The framework includes a nifty trick that enables you to use one CF template for both adding and editing records.

    Generic Deletion Prompt
    Virtually every data entry application I've ever written in which users could delete records required that they be prompted to confirm their request to delete a record. That's the purpose of the reusable template DeletePrompt.cfm. This template is entirely generic and can be reused from one application to the next. Its inner workings are detailed below.

    List Template
    A common starting place for desktop data entry apps is a tabular display that the user can browse through. The listing lets the user review the database records for the type of entity involved in the data entry application and is used as a starting point in the framework. Keep in mind that there's room for more diversity and creativity in Web-based applications than in traditional desktop apps. You don't have to start your applications with a "list template" but it's convenient. The framework is flexible enough that this template can be altered significantly or eliminated altogether. If you eliminate it, you'll need some other way of providing the list template's links with other templates in the framework.

    The list template (see Figure 2) provides not only a tabular listing for the user's perusal but also:

  • A button for adding new records
  • Links to edit records
  • Links to delete records

    My example consists of a Web-based catalog of music files that have been saved in the MIDI format. The catalog of tunes is stored in the Catalog table, which is the focus of our example data entry application. Figure 3 provides a listing of the Catalog table structure.

    Several fields are foreign keys to other tables. The ArtistID field points to records in the Artists table. Each entry in Artists describes a recording artist. The ProducerID field points to records in the Producers table (which describes producers of MIDI titles). The CategoryID field points to records in the Categories table. This table lists musical genres or categories (e.g., classical, hip-hop, jazz). The Categories table groups the entries in the Catalog table in a logical order. Each category is assigned a "sort position" (in the Categories table) indicating the order in which the Categories are to be displayed in the list page.

    The code for the list template can be found in Listing 1. Note that the Categories table is joined to the Catalog table because I want to display the complete category name (only the CategoryID is stored in the Catalog table) and because I need the SortPosition field for grouping.

    In this framework the list template always contains a form with a button for adding new records, as in this code snippet:

    <FORM ACTION="MaintainMIDIForm.cfm" METHOD="post"> <P><INPUT TYPE="submit" NAME="Add"

    VALUE="New Listing"> </FORM>

    The list template always lists the existing records, usually in tabular format (see the HTML table construction with CFOUTPUTs in Listing 1). The template always provides a link (i.e., an HREF anchor) that takes the user to a form for editing existing records. The list template also provides a link to delete records. If you need to prevent records from being edited or deleted, leave out the links. In other cases you may want the user to be able to view the entire record through your editing form, but not be able to edit it (i.e., you want to provide a read-only view of the data). I'll demonstrate how to do this later in the article.

    The HREF for invoking the editing form is pretty straightforward (from Listing 1):

    <A HREF="MaintainMIDIForm.cfm?Edit=#URLEncodedFormat(ItemNbr)#">#Title#</A>

    You pass the value of the key field to the editing template (in my example this is named MaintainMIDIForm.cfm) via a URL parameter named Edit.

    The HREF, which I build for deletion, is a bit more complex.

    <A HREF="DeletePrompt.cfm?Val=#URLEncodedFormat(Title)#&RT=Catalog&DURL=#URLEncodedFormat('MaintainMIDIDel.cfm?I=#ItemNbr#')#"><IMG SRC="../g/x.gif" WIDTH=12 HEIGHT=12 ALT="Delete" BORDER=0></A>

    As you may recall, a generic template, DeletePrompt.cfm, is used to prompt the user to confirm his/her intent to delete the record. You pass DeletePrompt.cfm the URL for the template you've produced to do the actual deleting of the record in the DURL parameter. In the previous code snippet DURL is set to 'MaintainMIDIDel.cfm?I=#ItemNbr#'. My deletion template is named MaintainMIDIDel.cfm. I'm passing it one parameter named "I" through its URL. The "I" parameter is set to the value of the ItemNbr field in the Catalog. In other words, I'm identifying the item to be deleted. I'm also passing two other optional parameters to the DeletePrompt.cfm template, Val and RT, explained below. Let's take a look at how the process of deleting works.

    Deletion Template
    The list template invokes the generic DeletePrompt.cfm template, which asks the user to verify that he or she wants to delete the specified record. (See Figure 4 and Listing 2.) If the user says "No," I return to the list template. If the user confirms the deletion, I want to run the template that actually does the deleting. Note that this form calls the DeletePrompt.cfm template recursively to process the user's selection.

    You write the template that does the deleting. This can't be done generically, because the process of deleting records can vary quite a bit from one data entry application to the next. As pointed out above, you pass the URL of your deletion template to DeletePrompt.cfm in the DURL parameter (see Listing 1).

    DeletePrompt.cfm includes two optional URL prameters that you'll find useful. The RT URL parameter allows you to specify the type of record being deleted. If you specify an RT, it will be included in the prompt presented to the user. I'm deleting Catalog records, so RT has been set to "Catalog" in the URL for DeletePrompt.cfm. The second optional parameter, Val, lets you provide a value that'll be presented at the end of the prompt to identify the specific record being deleted. I've set Val to the song title from the catalog. Again, using this parameter helps to further customize the deletion prompt so the user is clear about what is about to be deleted.

    If the user doesn't want to delete the record, I return to the list template without invoking the deletion template. This can be done through JavaScript (as in the code provided) or through a regular form submission. If you don't want to use JavaScript, you can make it work through a form submission by changing the input object from type "button" to type "submit" and removing the onClick="history.back();" JavaScript code from the button. Doing so causes the form to be submitted for processing on the server when the user clicks the No button. If the No button exists when the DeletePrompt.cfm is called recursively, the user is redirected (through CFLOCATION) to the URL stored in the CT field, which is built dynamically when the form is first displayed. It contains the URL of the template that invoked the DeletePrompt.cfm in the first place, i.e., the list template. Note that I'm simply setting CT to the value of the CGI variable HTTP_REFERER:


    What happens if the user does want to delete? Again, the DeletePrompt.cfm form invokes itself to process the form submission. This time, however, the Yes input object will exist (the user clicked the Yes button, right?). In this case processing is simply redirected to the URL that was passed to DeletePrompt.cfm in the DURL parameter.

    <CFELSEIF IsDefined("Form.Yes")>

    This URL value was stored in the hidden field that we also named DURL.


    Remember that this is the URL to your custom template for executing the deletion. Here's the deletion template used in this example (the file name is MaintainMIDIDel.cfm):

    <CFQUERY NAME="DeleteItem" DATASOURCE="#DataDB#">
    DELETE FROM Catalog WHERE ItemNbr=#URL.I#
    <CFLOCATION URL="MaintainMIDIlist.cfm?Function=delete">

    I defined one parameter, URL.I, to pass the ItemNbr to be deleted. Where did the URL.I come from? From the URL that was created back in the list template. After the record is deleted, I redirect the user to the list template. The deletion templates you create for your applications will execute different code, obviously, but they'll be structured to do the same thing - delete the specified record(s) and direct the user back to the list template. (The Function=delete query string on the URL will be explained shortly.) Let's see how we can use one form to add new records and edit or view existing records.

    Form Template
    The form template presents a formatted view of an individual record. (See Listing 3 and Figure 5.) The data entry form you use to add records doesn't need to be very different from the form you use to edit records. In some applications you may need to prevent the user from editing key field values (once they've saved the record). There may be some other minor differences too, but usually the forms function similarly. Using two forms is more than a waste of effort; the real problem occurs at some point in the future when you're asked to change the way processing works. Perhaps a field should be removed or added. With two forms you'll have to go to two places to make the same adjustment and this increases the chances of making an error or omission. Using a third form for presenting a read-only view of the individual record makes things even worse.

    Let's take a look at how the list template invokes the form template when a new record is to be added. A simple form at the top of the list template contains one submit button named Add. While the list templates you create for your applications won't look the same as this one, the approach for invoking the form template is the same.

    <FORM ACTION="MaintainMIDIForm.cfm" METHOD="post">

    <INPUT TYPE="submit" NAME="Add" VALUE="New Listing"> </FORM>

    If you're editing an existing record, the form template is called through a URL that includes a parameter named Edit, which is set to the key value of the record to be edited. A little chunk of code near the top of the form template is used to determine the context in which the template is being called:

    <CFIF IsDefined("Form.Add")>
    <CFSET Function="add"> á
    <CFELSEIF IsDefined("URL.Edit")>
    <CFSET Function="edit"> á

    So it's the presence of one of these two parameters that enables the template to determine the context in which it was invoked. It then instantiates the Function variable with either "add" or "edit". This little chunk of generic code should be used in your form templates.

    Your data entry forms are composed of HTML form elements. When you're editing a record, you need these elements to reflect the values in the existing record. This is typically done by querying the desired record from the database and creating a variable (with the value from the database) for each field that the users are allowed to edit. These variables are then used to populate the values of the form's INPUT, TEXTAREA and SELECT elements.

    But what about a new record? There are no values that you need to populate the fields with (unless, perhaps, you need some fields populated with default values). Should you build another set of logic to handle the HTML form elements when working on new records? There's no need to - the framework includes a reusable technique for this.

    Do a "SELECT * FROM..." query to retrieve a record from the table you're editing containing all the fields in the table. (It doesn't have to retrieve all the fields, but it should return the fields needed to add or edit records.) When you're working on an existing record, you've passed the key of the record to be retrieved to the form template via the URL.Edit parameter. When you're working on a new record, create a "WHERE" clause that returns an empty data set. In both cases, after you run the query you have a CF query object you can use to derive the field names of all the fields in the record. Here's the query from my example:

    SELECT * FROM Catalog WHERE ItemNbr = <CFIF Function IS "add">-1
    <CFELSEIF Function IS "edit">#URL.Edit#</CFIF>

    If I'm adding a new record, we query for the record where ItemNbr is -1. I do this because I know there are no records with -1 as the item number. Thus I'm using one query to deal with both new and existing records.

    In my example the query I'm running is named GetRec. The following code snippet creates a variable named after each field. The value will be set to the value in the underlying record. If the record is null - as it is with a new record - the variable will have a null value.

    <CFLOOP LIST="#GetRec.ColumnList#" INDEX="ii">
    <CFSET x = #SetVariable( ii, Evaluate("GetRec." & Evaluate("ii")))#>

    After this code executes, I'm assured of having one variable for each field in the table. I can now use these variables to populate the INPUT, TEXTAREA and SELECT objects in our form regardless of whether I'm working on new or existing records (see Listing 4).

    Note the trick employed in the form template with the checkbox input named FreeYN. When a form with an unchecked checkbox is submitted, HTTP handles it in an unexpected manner. The value and the name of the checkbox input aren't passed to the processing template. As far as you can tell in the processing template, the checkbox input doesn't exist.

    <INPUT TYPE="hidden" NAME="FreeYN" VALUE=""><CFOUTPUT>
    <INPUT TYPE="checkbox" NAME="FreeYN" VALUE="X"
    #Iif(FreeYN EQ "X", DE("CHECKED"),DE(""))#> Free?

    By including a hidden field in our form, using the same names as the checkbox input (i.e., FreeYN), I'm assured that the variable, form.FreeYN, will exist in the processing template. If the user didn't check the box, then form.FreeYn will have the null value it gets from the hidden input object. If the user does the box, then form.FreeYN will have the value x (which is what I need to save in the associated database field). This approach means I don't have to include any logic in the processing template to check for form.FreeYN's existence.

    A number of select objects displayed as dropdown lists are used in this form template to provide a list of valid entries for the associated fields ArtistID, ProducerID and CategoryID. I've used CFSELECT rather than a plain old HTML SELECT because it simplifies the job significantly. The value stored in the field is usually a code or an ID, but I want the user to be able to select from lists containing artist, producer and category names. This task is simplified by using the CFSELECT object's VALUE and DISPLAY attributes. These three dropdown lists need to be handled differently depending on whether the user is editing or adding.

    If the user is editing, these fields (ArtistID, ProducerID and CategoryID) already contain values. While the entire list needs to be presented, the current value needs to be selected. This task is made considerably easier by the CFSELECT's SELECTED attribute. If the user is working on a new record, however, these fields will be null; therefore, there is no value to select by default. This is the reason for the chunk of logic for each CFSELECT - to determine whether the user is adding or editing.

    <CFIF Function IS "add">
    <CFELSEIF Function IS "edit">

    Handling Read-Only Access
    You may have applications in which you are required to provide a read-only level of access to certain people. In my experience this is generally handled by assigning people to specific groups or by assigning different "rights" or privileges to a person. How do I accommodate this requirement in my framework? Do I provide a separate read-only template for certain people? You can probably guess my answer: of course not!

    To accommodate users with read-only privileges, I add a little logic to the code chunk that determines the function, and to the field display. Suppose you have a session variable named ReadOnly that stores a Yes or No indicating whether or not the current user has read-only rights. The code chunk could be modified as follows:

    <CFIF Session.ReadOnly IS "Yes">
    <CFSET Function="view">
    <CFELSEIF IsDefined("Form.Add")>
    <CFSET Function="add">
    <CFELSEIF IsDefined("URL.Edit")>
    <CFSET Function="edit">

    Farther down in the form you'd include logic to display the field: <CFIF Function EQ "view">
    <CFOUTPUT>#Replace(Description, chr(10),
    ", "all")#</CFOUTPUT>
    <TEXTAREA NAME="Description" COLS=50

    When you need to display the contents of TEXTAREAs in a display-only format, you can use this trick to force hard carriage returns that the user may have entered in the field: replace all of the line feed characters (ANSI character 10) with a BREAK tag (
    ). This is done in the previous code snippet with the line:

    #Replace(Description, chr(10), "
    ", "all")#

    There's another, simpler way to handle the folks who have read-only access: rather than having a separate set of logic for producing read-only text rather than HTML form objects, don't include a Save button in the form. Alternatively, you can include a button that returns the user to the calling template. The point is, don't execute the code that saves the data. I generally don't use this approach because if you give users the ability to change the data - or at least don't stop them - they'll expect to be able to save whatever changes they've made.

    Dealing with Keys
    One of the subtle complexities in developing Web-based database applications is the Back button. What happens, for example, when a user adds a new record to the database by submitting a form and then hits the Back button in his browser, goes back to the form and tries to submit the form again? Well, what shouldn't happen is the record should not be added again. If you don't do anything to prevent this situation, however, you can bet it will happen.

    Here's a relatively simple approach that can be modified to deal with different circumstances. The general idea is that you create a unique number in advance, before the form is initially presented to the user. You include this number in a hidden form field. When the user submits the form to add a new record, you first check to see if the number has already been used; if it hasn't, you create a new record using the number. If the number has been used, you can display an error message telling the user not to resubmit records, or something to that effect.

    Here's how I use the technique in my example. The Catalog table is keyed on the ItemNbr field, which contains a unique number in each record. I have a custom tag named NEXT_NBR that generates sequential numbers for specified fields. It works in conjunction with a table called NEXT_NBR. As you can see in Figure 6, NextNbr stores the next available number for use in two fields, CustomerNbr and ItemNbr. You can use other fields in your data entry applications.

    When you call CF_NEXT_NBR, you indicate the datasource for the NextNbr table and the name of the field for which you want the next available number (the code for NEXT_NBR.CFM is included with the rest of the source code for this article). You can optionally specify the name of the variable you want created in your template to store the next available number. In my example I tell it to create a variable named ItemNbr.


    I store the value of the next number in a hidden INPUT named ItemNbr. When the user submits the form and the Function is "add," the post template checks to see if there's already a Catalog entry with this value. If there is, we know the user is trying to resubmit the same information and an error message is displayed (see Listing 4).

    This functionality is needed only when you're adding new records to a table. But in the posting template how does it know whether I'm posting newly added records or modified existing records? Simple: in my data entry form I include a hidden INPUT that stores the value of the Function variable ("add" or "edit").

    The next number process can be made more efficient by using Application-level variables to store the next available number. The idea is that you'd get the next number when the application is initialized but save the next number to the NextNbr table only intermittently, perhaps every hundred numbers or so. This significantly cuts down on the I/O used by the approach described above. Well, I've started to get into issues relating to the posting template, so let's move there.

    Post Template
    The final template in my framework is used to save modified and newly created records into the database. It's invoked from the FORM ACTION in the form template (MaintainMIDIForm.cfm in my example). After the record has been dealt with, the user is redirected to the list template. Let's examine the post template (MaintainMIDIPost.cfm) in more detail.

    It starts by determining whether it needs to add a new record or update an old one. There's a separate set of logic for each alternative. If I'm adding a new record, the query described in the previous section is executed. This query determines whether the new record has already been posted to the database.

    <CFQUERY DATASOURCE="#DataDB#" NAME="CheckForDuplicates">
    SELECT ItemNbr FROM Catalog WHERE ItemNbr = #Form.ItemNbr#

    Next, I check to see if the query returned any rows. If it did, I display an error message and abort further processing. I'm using a custom tag called CF_SHOWERR. You can display your error message however you like.

    <CFIF CheckForDuplicates.RecordCount GT 0>
    ErrorTitle="Problem Saving New Record"
    ErrorMsg="The database already contains a
    catalog listing with this number|Try
    starting over"

    Next, my posting template calls another custom tag, CF_REPLACEPIPESINFIELDS. This tag is extremely handy if you're working with MS Access databases and your input form includes INPUTs or TEXTAREAs that enable the user to enter free form text. For some reason the ODBC driver for Access won't let you insert the pipe character ( "|") directly into a table. This tag searches through the form variables you specify in its FieldNames attribute and replaces any pipes it finds with "|Chr$(124)|". For some reason Access allows this. Go figure. (Mateo Ferrari turned me on to this trick and I took it and turned it into a custom tag. Thanks, Mateo!)

    The post template then calls either an insert query or an update query to post the record. A trap to watch out for has to do with posting null values. MS Access text fields and memo fields have an "Allow Zero Length" property that takes a Yes/No value. You usually set this to Yes. If you leave it set to No and try to execute an insert query that contains a null value for one of your text or memo fields, the query will fail and the user will get an ugly error message. While it's safer to set this property value to Yes, that isn't necessarily enough.

    If you're working with SQL server databases or if there's a chance that someday you may, write your queries so you never write null strings (i.e., "") into SQL server fields. Why not? Because they'll be inserted as the ANSI 32 character, i.e., a space (" "). To prevent this, always include code in your insert and update queries to check for empty strings and in their place use the SQL reserved word NULL. It's imperative that you don't insert this as text string. In other words, do not surround it with double or single quotes. Instead, use the word NULL as I've done in the example (see Listing 4).

    The last task performed by the post template is to redirect the user back to the listing template. This is done with the last line of code.

    <CFLOCATION URL="MaintainMIDIList.cfm?Function=#URLEncodedFormat(URL.Function)#">

    Why am I passing the query string Function=#URLEncodedFormat(URL.Function)# back to the list template? Perhaps you remember that I did something similar in the deletion template. It's really very simple. The list template has some logic in it to provide the user with feedback on what just happened.

    <CFIF IsDefined("URL.Function")>
    <P><FONT COLOR="Red">
    <CFIF URL.Function EQ "edit">
    Your record was successfully saved.
    <CFELSEIF URL.Function EQ "add">
    Your record was successfully added to the
    <CFELSEIF URL.Function EQ "delete">
    Your record was successfully deleted from
    the database.

    Note the message, in red, in Figure 2. Well, that pretty much wraps it up.

    The real benefit of these techniques comes when you develop - and have to support - a number of data entry applications. If you adopt a framework and use it consistently from one app to the next, your work will become easier to maintain. If you follow my suggestions regarding naming your templates, they'll be easier to find. If you apply the same techniques within each type of template, your apps will be easier to maintain because you'll have a good idea of the techniques used in the template even if you've long since forgotten the original function of the app.

  • More Stories By Leon Chalnick

    Leon Chalnick is the President of Professional Presence Providers, Inc. (PR3), of Long Beach, California. PR3 develops web applications for intranets and the Internet. Leon has written numerous articles on Cold Fusion and is a contributing author to Que's ColdFusion Web Database Construction Kit and ColdFusion Web Application Development Kit, in addition to several other database oriented books.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

    IoT & Smart Cities Stories
    The challenges of aggregating data from consumer-oriented devices, such as wearable technologies and smart thermostats, are fairly well-understood. However, there are a new set of challenges for IoT devices that generate megabytes or gigabytes of data per second. Certainly, the infrastructure will have to change, as those volumes of data will likely overwhelm the available bandwidth for aggregating the data into a central repository. Ochandarena discusses a whole new way to think about your next...
    CloudEXPO | DevOpsSUMMIT | DXWorldEXPO are the world's most influential, independent events where Cloud Computing was coined and where technology buyers and vendors meet to experience and discuss the big picture of Digital Transformation and all of the strategies, tactics, and tools they need to realize their goals. Sponsors of DXWorldEXPO | CloudEXPO benefit from unmatched branding, profile building and lead generation opportunities.
    All in Mobile is a place where we continually maximize their impact by fostering understanding, empathy, insights, creativity and joy. They believe that a truly useful and desirable mobile app doesn't need the brightest idea or the most advanced technology. A great product begins with understanding people. It's easy to think that customers will love your app, but can you justify it? They make sure your final app is something that users truly want and need. The only way to do this is by ...
    Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to ...
    Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...
    DXWorldEXPO LLC announced today that Big Data Federation to Exhibit at the 22nd International CloudEXPO, colocated with DevOpsSUMMIT and DXWorldEXPO, November 12-13, 2018 in New York City. Big Data Federation, Inc. develops and applies artificial intelligence to predict financial and economic events that matter. The company uncovers patterns and precise drivers of performance and outcomes with the aid of machine-learning algorithms, big data, and fundamental analysis. Their products are deployed...
    Cell networks have the advantage of long-range communications, reaching an estimated 90% of the world. But cell networks such as 2G, 3G and LTE consume lots of power and were designed for connecting people. They are not optimized for low- or battery-powered devices or for IoT applications with infrequently transmitted data. Cell IoT modules that support narrow-band IoT and 4G cell networks will enable cell connectivity, device management, and app enablement for low-power wide-area network IoT. B...
    The hierarchical architecture that distributes "compute" within the network specially at the edge can enable new services by harnessing emerging technologies. But Edge-Compute comes at increased cost that needs to be managed and potentially augmented by creative architecture solutions as there will always a catching-up with the capacity demands. Processing power in smartphones has enhanced YoY and there is increasingly spare compute capacity that can be potentially pooled. Uber has successfully ...
    SYS-CON Events announced today that CrowdReviews.com has been named “Media Sponsor” of SYS-CON's 22nd International Cloud Expo, which will take place on June 5–7, 2018, at the Javits Center in New York City, NY. CrowdReviews.com is a transparent online platform for determining which products and services are the best based on the opinion of the crowd. The crowd consists of Internet users that have experienced products and services first-hand and have an interest in letting other potential buye...
    When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...