Skip navigation
All Places > Esri Technical Support > Blog > Author: NSager-esristaff
This blog post is the third in a series of JavaScript debugging tips and tricks to help you on your way. See JavaScript Debugging Tips Part I  and also JavaScript Debugging Tips Part II for our previous segments.

In the past two JavaScript Debugging Tips posts on the Esri Support blog, we looked at the Network Tab and the Console Tab as part of the Google Chrome Developer Tools. While most modern browsers have some form of developer tools, here we use Chrome for our examples.

Our goal for this third blog post in the series is to introduce more advanced tips and tricks to enable you to more effectively debug and troubleshoot your JavaScript code. Specifically, we will focus on three areas: enhanced messaging to the console, better ways to set breakpoints using conditions specified at runtime, and a more efficient way of stepping through breakpoints in the Sources tab with a method called blackboxing.Part 1: Console.table

Console.log is our primary debugging function, but this function's output can be a bit difficult to read (especially when viewing a lot of data). One way to enhance our console log messaging and view data more easily is to display a list of objects as a table, which is accomplished using the console.table function. This function takes one mandatory argument, which must be an array or an object, and one additional optional parameter. Each element in the array is a row in the table.

Let’s take a look at the Console Table sample.

1. Open the Chrome Developer Tools by using shortcut keys (Windows: Control + Shift + I, and Mac: Command + Option + I), or by navigating to the top right-hand pane of the browser, clicking the three grey vertical dots, and choosing “More tools” > “Developer tools”.

2. Select the console tab.

3. Click “Perform Query” in the sample application. This performs a query task to view all counties in Connecticut. The code uses the console.table to print the results in a table as shown below.
console.table_.png

console.table



Every row in the table shows all attributes for a specific county. Next, we use the console.log to compare the console.log and console.table. This function will print a line with an array of objects.
console.log_.png

console.log



Once we expand the array, we can view the objects in a list.
console.log-expanded.png

console.log expanded



To view the attributes, we must expand the objects in the list.
console.log-expanded-with-attributes.png

console.log expanded with attributes

While we can access the attributes of one feature when using console.log, we can view all attributes for all features at once using console.table! The image below shows both functions in the console window.
console.table-console.log_-e1496352191442.png

console.table & console.log

Part 2: Conditional Breakpoints

In JavaScript Debugging Tips Part II, we talked about setting a breakpoint in the Sources tab, refreshing the application, and pausing the application at that line of code. This is a great way to examine your code and how functions are called, and where potential areas of trouble could arise.

However, sometimes we don’t want the breakpoint to be reached every time. Sometimes we only want the breakpoint to be reached if certain conditions are met. While we could write some logic code in the form of a loop to check for values, there is an easier way to do this at runtime.

For example, let’s look at a sample.

1. Open the Edit Features sample and the Chrome Developer Tools.

2. Navigate to the Sources tab, and left-click line 301 to set a breakpoint there.

3. After the breakpoint is set, right-click the breakpoint and select “Edit breakpoint…”.
EditBreakpoint2.png

Edit Breakpoint

Note: We could also get here by first right-clicking line 301 and selecting “Add conditional breakpoint…”.
AddConditionalBreakpoint1.png

Add Conditional Breakpoint



4. Set a condition whereby the breakpoint will be reached only if the user inputs “test” into the “Contact:” field when updating a feature. Here is the code: editFeature.attributes["Incident_Address"] == “test”Note: We do not want to use "=" because this assigns a value and thus always returns true, so we must use "==".
BreakpointExpression1.png

Breakpoint Expression



5. If we input “test” for the “Contact:” and click “Update incident info”, the breakpoint will be reached and the application pauses.
ConditionMet1.png

Condition Met



These conditional breakpoints can be useful for testing when you want to ensure data is sent back to the server correctly, or for error handling when you want the application to pause so you can inspect the object(s) of interest rather than letting your error handling code take over.Part 3: Blackboxing

While setting breakpoints is a great way to make friends and go through your code, this process can occasionally kick you out of the file of interest and into another source file or into a third-party JavaScript library.

For example, let’s look at a sample.

1. Open the Query SceneLayerView sample to follow along (this is similar to the sample found on developers.arcgis.com).

2. Open the Chrome Developer Tools, select the Sources tab, and left-click line 49 to set a breakpoint.

3. Refresh the page so the debugger pauses on line 49. From here, a "Paused in debugger" message appears (next to a "Play" button and a "Step Over" button). See below for a screenshot.
PausedAtLine49.png

Paused At Line 49



4. If you click the "Step Over" button about five times, you exit out of the main .html file and into the init.js file of the ArcGIS API for JavaScript. You can explore the init.js file, but we want to focus on the code that we wrote. Click the "Play" button to get home safely.
DebuggerInInitJSFile.png

Debugger in init.js file



Enter blackboxing to save the day. Blackboxing is a method to exclude files and libraries from the debugger, so that your focus remains on your file(s) of interest. Let’s take a look at how we can blackbox the ArcGIS API for JavaScript library so we can just step through the main file of interest.

1. With the Developer Tools open, click the three vertical dots in the far right-hand pane of the window and select Settings.
Developer-Tool-Settings.png

Developer Tool Settings

Developer-Tool-Settings2.png

Developer Tool Settings



2. On the left-hand side of the window, click “Blackboxing” to open the “Framework Blackbox Patterns”.
Blackboxing.png

Blackboxing



3. Click the “Add pattern…” button, and enter this framework pattern: js.arcgis.com.*\.js
Blackboxing-Pattern.png

Blackboxing Pattern



4. Click “Add” and check the box above the pattern input to “Blackbox content scripts”.

5. Close the Settings window and return to the Sources tab.

6. Refresh the page so the debugger pauses on line 49.

7. If you click the "Step Over" button about five times, you exit out of the main .html file and into the debugger:///VM file (this is an empty function which you can safely ignore, or read more about here), as well as complete one more "Step Over" operation into the application. Now rather than debugging unnecessary, ancillary libraries, you can focus on debugging the code you wrote or are trying to understand.Debug_Blackbox.gif

One last point worth mentioning is that blackboxing applies to the browser, not just to the webpage or web app of interest. After testing completes, feel free to remove the blackboxed pattern(s) to ensure a conventional web browsing experience.

This concludes our blog about advanced tips for using the Google Chrome Developer Tools with examples from the ArcGIS API for JavaScript. We hope you found the above tips useful and entertaining. For more information about debugging tips with JavaScript applications, here are a couple additional resources from the past several years:Additional Resources
Join us next time as we continue to delve ever deeper into Developer Tools and learn some valuable lessons. Happy debugging!</span>

Artemis F. and Noah S. - Esri SDK Support
This blog post is the 2nd in a series of JavaScript debugging tips and tricks to help you on your way. See JavaScript Debugging Tips Part I – Google Chrome and the Network Tab for our first segment.


The most enjoyable part of any programming assignment is right near the beginning when you sit down with a pile of tools and resources and start hammering away at raw clumps of code. The more difficult part comes when you attempt to launch the application, only to watch that tightly-written code unravel into multiple late nights staring at a computer screen. However, all is not lost, as we have an excellent recommendation for you, which is the subject of this blog: the Console tab inside your favorite browser's Developer Tools.

If you’re feeling upset or emotional, the Console tab is the perfect choice for you. Maybe someone in your family is dealing with a difficult time, and could use some cheering up. Consider the Google Chrome Console tab (gluten free options are available). Users who like the Console tab might also enjoy the ArcGIS API for JavaScript.
Sad_Console.png

I obviously do not understand homographs



As we wrote in Part I, accessing the Chrome Developer Tools is easily done using shortcut keys (Control + Shift + I) or by navigating to the top right of the browser, clicking on the hamburger and choosing “More Tools”, then “Developer tools”.

Once the Developer Tools are open (other Developer Tools are available in other browsers), there are several Tabs that become accessible to you. Here we will focus on the Console. If you want to open the Console tab in Chrome Developer Tools directly, use this keyboard shortcut: Control + Shift + J (the “J” stands for jocular). For more neat tips, please check out the official Google documentation about Chrome DevTools: Using the console.

The Console is used for two purposes: 1) to display logged information from an application's JavaScript (usually during application development), and 2) to interrogate objects and execute JavaScript interactively. In this blog, we will look at both kinds of examples, and elaborate on some additional tips and tricks that we use in Technical Support.

The first thing we can do is to add some “console.log” statements inside our application. We will take a modified sample, hosted on GitHub, which can be found here: Sample Console Application. Feel free to follow along at home.

At lines 60-62, and again at line 66, we’ve added some of those “console.log” statements to display information about our Feature Layer. Our use case is that we are creating a web mapping application, and during our testing, we want to ensure that the data we are consuming from ArcGIS Online is the correct data to display on the map. To this end, we print out a few choice pieces of information about the Feature Layer: the title of the layer, and the URL of the layer. Since I do not know the syntax for the URL property, I use “URL” and “url” as seen below.
ConsoleLog_JavaScriptCode.png

JavaScript console.log statements



Here is a screenshot of the output of the “console.log” statements. We see the relevant information we were expecting. Also, please note that the output for “featureLayer.URL” is “undefined”. This is because items in the console are case sensitive. The valid property is “featureLater.url”, and invalid properties do not throw an error, and instead return an undefined result. This can be a tricky thing to trap, but later on in this blog we will look at some tips for dealing with this sort of issue.
JavaScript_Write_To_Console_Example1.png

JavaScript Console Output from console.log



With the Console still open, let’s try entering the same property values from the code:

featureLayer.titlefeatureLayer.URLfeatureLayer.url


Notice that all of these properties now return an error, instead of an actual value (or even “undefined”). This is because the local variables are no longer in scope after the app is initialized, so even the “featureLayer” object cannot be recognized.  Here is a screenshot of the output of the new console statements.
JavaScript_Write_To_Console_Example2.png

JavaScript Console Output after App is loaded



If we had made “featureLayer” a global variable, we would then see “undefined” returned for the object in the Console (variable is known, but the details are still not accessible). The point is: only variables that are in scope can be interrogated in the Console. So can we use the Console interactively and type in property values? Let’s find out.

The next thing we can do to our sample app is to add a “debugger;” statement in the code. We will take another modified sample, hosted on GitHub, which can be found here: Sample Console Application 2. Feel free to follow along at home.

At line 60, we’ve added a “debugger;” statement to help display information about our Feature Layer in the Console.
JavaScript_Write_To_Console_Example3.png

JavaScript debugger statement



How does this statement work? Click the link to run the application. Then, open the Developer Tools (Control + Shift + I or Control + Shift + J), and refresh the application. The application should pause, and you should see a “Paused in debugger” message at the top of the screen, and the “debugger” line highlighted in the Sources tab:
PausedDebugger2.png

Paused in debugger 1



Now, with the application paused, we can go back to the Console tab, and try interrogating the featureLayer properties again. Here we see that we have proper scope to the variable and we can see the output:
PausedDebugger3.png

Paused in debugger 2



Cool, right?

Let’s look at another option, similar to “debugger”. Back to the Sources tab, notice the line numbers to the left of the code. If we left-click on a line number, we can set a breakpoint, which will have the exact same effect as writing “debugger” in the code. Left-click on lines 56, 62, and 66 in the same application, then refresh the application.
Breakpoint1.png

Breakpoint 1



The application pauses immediately at the first breakpoint. Now, we could go back to the Console tab and again inspect variables and properties to our heart's content. Not only that, by clicking the curved arrow to the right of the Play button at the top of the screen, we can step through our application and watch the excitement as we see how the code executes step-by-step. Or, we can click the Play button at the top of the screen, and let the application run to completion, or to the next breakpoint.
Breakpoint2.png

Breakpoint 2



And another Play button click brings us to the next breakpoint.
Breakpoint3.png

Breakpoint 3



The point of this blog is to highlight the usefulness and functionality of the Console, but we do want to point out another usage of setting breakpoints here as well. Breakpoints allow the developer the ability to see the order in which asynchronous code executes, how functions are run and what parts get skipped or fail. For more information about debugging tips with JavaScript applications, here are a couple additional resources from the past several years:
In this installment, we learned how to access and use the Console tab inside Chrome Developer tools to reveal the properties and values of variables and objects in our JavaScript code. This information can greatly facilitate the debugging and coding of a web-based application. This concludes part two of a multi-part series on JavaScript Debugging Tips. Join us next time when we delve even deeper into some Developer Tools, and we all get raises. Happy debugging!
Noah S. and John G. - SDK Support Services
Now that the ArcGIS API for JavaScript 4.0 has been released for a couple of weeks, this is an excellent opportunity to take a walk through some of the new syntax and functionality. This blog will go through a sample 3D application focusing on the Search widget. You can follow along with the sample code from the Esri Developer Support GitHub repository, and run the hosted sample here: View it Live.

Functionality-wise, the app displays a 3D map with four widgets: Search, Zoom, Compass, and Attribution. By default, the View includes the latter three widgets, as described in the documentation. If you’re not familiar with the 4.x changes, all mapping apps contain a map and a view. The map holds the data, and the view contains the visualization information for that data. In other words, the map is the subject, and the view is the camera; complete with filters, modes, and settings. All 2D apps will have MapViews, and 3D apps will have SceneViews (note: the term ‘scene’ indicates three dimensions across ArcGIS). The same applies for maps from ArcGIS Online and Portal for ArcGIS: a WebMap is 2D, and a WebScene is 3D.
2d3d_2-1024x662.png

2D map + 3D scene



You can input a location in the Search widget and either select a result from the drop-down suggestions, or press Enter on the keyboard to go to the first place in the list. The view will zoom to that location and place a picture marker symbol on the map. If you open the Developer Tools in the web browser, you will see some helpful console log messages indicating the progress of the Search widget.

In the code, there are many helpful comments describing the functionality, with links to references to find more information. The Map and SceneView constructors might be new, but they are very straightforward. What I want to focus on here are two things: the SearchViewModel (beginning on line 88), and the view.ui (beginning on line 117).

One of the awesome features of 4.0 is the separation of the styling and the business logic. This means that widgets have a view and a ViewModel. The view is the widget itself and handles the display of the widget, while the ViewModel handles the properties and configurations. I should mention that we don’t have to use the ViewModel if we don’t want to since the ViewModel properties are also wired to the widget view. This was done for simplicity purposes. As an example, let’s look at the Search widget in the code:
searchWidget.png

Search Widget and SearchViewModel



The actual widget constructor was used for naming the widget and setting the visibility to true (default is true anyway). The SearchViewModel handles all the configurations that were set to customize the user experience and interface the way I needed (see the sample for comments). What’s interesting about this ViewModel system is because it's separated from the widget constructor, it’s now way easier to share business logic amongst widgets and code bases. Here is some more information about the SearchViewModel.

The second interesting aspect of 4.0 I will discuss here is how we add the Search widget to the app. Let’s look at the code snippet from 4.0 and from 3.x. Currently, we can add the widget directly to the view’s user interface without creating a separate div element. This is an efficient (and dare I say, elegant) workflow.
addSearchWidget4.png

Add Search Widget 4.0



At the 3.x versions, we need to create a div element, reference the div when the widget is created, and reference it again inside the HTML body tag.
addSearchWidget3.png

Add Search Widget 3.x



For more information about adding widgets to the view, you can reference this documentation.

In summary, the ArcGIS API for JavaScript is a powerful product that leverages the power of GIS directly on your web browser. If you’ve been working with earlier versions of the API, reading the Transition to 4.x help document can get you going. And if you’re brand new, you can start with the Discover 4.x Guide. There’s a lot more to come as we continue to add functionality and awesomeness to the JavaScript API 4.x. Happy coding!
Noah S. - SDK Readiness Lead
Esri Technical Support is unlike any other Technical Support on the planet. But if you’ve ever opened a Support case before, you already know that. We provide world class support to our customers to help make them as successful as possible with our technology. But if you’ve ever come to one of our conferences or technical workshops, you already know that.

However, what you don’t know may mildly surprise you. I would like to take this opportunity to shed some light on how Support works, and help make you both more successful and more effective with your troubleshooting.
support_photo2.jpg

Excited Esri Support



I wrote a totally rad blog post back in the day about what it feels like to work as a Support Analyst. It’s a pretty sweet job, and after two years, I still maintain the sentiment that Support is full of super awesome and intelligent people who kick serious butt and take great pleasure in helping our customers. Therefore, it might (or might not) come as a surprise that in Support we can’t (all) be GIS prodigies with experience on every product or subject matter. Sometimes we need to do a screen-sharing session so we can both look at the same product/documentation together. Sometimes we have to test offline and get back to you later. Sometimes we need a senior colleague to assist, or need to transfer the case to another analyst who is better suited for the specific technology/question. I know that this is a racy topic, but my goal here is to concurrently increase our transparency and your success.

To paraphrase our ultimate goal: we want to help you. I would put the emphasis on “want” in that statement to make sure that our intentions are clear: we want to help you. We also love you. Actually, love is a strong word, so let’s just say that we really really like you. So, you know that we like you, you know that we want to help you, now the next step is to help us help you. But the question is, how?
Support-Analysts-at-Work.jpg

Support Analysts at Work



First, we’re all human beings. We think and we feel and we try really hard. We’re also professionals, so we will do our best to help you, and at the same time, achieve our own personal/professional goals. That’s a pretty vague statement, right? So let’s look at an example. Someone calls in with a question about the JavaScript API. I answer the question to the best of my abilities, but not everything worked out the way we wanted it to, and the customer gives me a bad survey. This hurts my feelings, but I talk to my manager and my manager talks to the customer, and we all learn something. This is another good nugget of information: every single survey is read and considered. If you have kind words to say, say them - we love to hear them. If you are upset and feel that something went wrong and have strong words to say, say them - we need to hear them too. Remember, as technologically savvy as we are, we are still human beings and thus imperfect and also warm and cuddly and willing to learn.

Second, when you call/email/chat to create a new Support case, we do our best to route you to the correct analyst. Our analysts specialize in particular areas of our technology, so not everybody knows everything. You may need to be rerouted to accomplish this goal, but just remember that we want to help you. We are proud to say that we are constantly working on refining and streamlining this process. Even though it’s not perfect, it’s always getting better. Kind of like a piece of software, case management is always being upgraded based on user feedback and experience. Also, when logging new cases, please include as much relevant information as possible, including specific product names and versions. Copy and paste is both of our friends. Test applications and screenshots are good buddies too. We also accept cookies.
another_team.jpg

Support Celebrates GIS Day



Third, you know how they say at the end of some commercials: “Prices and participation may vary”? Well, it’s the same with Technical Support. The prices of our services, such as a Support contract, Premium Support contract, or a Professional Services contract, do indeed vary. Our Customer Service representatives or Account Managers would be happy to review these options with you. With regards to participation, your participation is vital. We need to be able to have an honest conversation, and we need you to hold up your end just as we need to hold up ours.  If you leave to go on vacation, or can’t work on something, just let us know so that we can temporarily close the case and then reopen the case when you are ready to participate. Remember that we really, really like you, but without you, there is no case.

Fourth, we maintain a standard of one topic or question per case. Why do we do this? For many well-intentioned reasons. For one thing, it’s good for our internal resources. We are able to track and research on past cases, and it’s quite helpful to have one question and one answer in each case in order to quickly find the information that we need to help future customers. Another reason is that we need to help all of our customers in a timely manner. If there is another question or issue that arises during the current case, we need you to create a new case that goes back in the queue so that the next available analyst can handle it. This way we always work on a “first come first served” basis, and we don’t (read: can’t) play favorites. Lastly, we do this because there must be a light at the end of the tunnel. These cases could drag on for longer than necessary if we don’t have a firm resolution timeline in mind.
Support-Analysts-at-Another-Hackathon.jpg

Support Analysts at a Hackathon



Sixth (I skipped number five to save space), some of us use a lot of exclamation points in our emails and chat interactions. You may find this bizarre or annoying, but believe me, we are not being annoying! We are also not shouting or saying things emphatically. We just do it because it seems nice that way!!

Seventh, we love closing Support cases. It’s a bit hard to explain, but when we’re given a problem, and we can figure it out and send someone on their way towards success, it feels so freaking good - you have no idea. And even when a case gets closed, we can still re-open it if something bubbles up down the road, or if you have a question about a topic that was covered during the case. Nothing is forever, not even closure.

I write these words to help. Real life is about people trying to live their lives to the best of their abilities, so why should professional life be any different? We’re here to help, plain and simple. Maybe they do things differently on Mars, but here on Earth, this is what world class technical support looks like. And you’re a part of it.
Support-Analysts-at-a-Hackathon.png

Support Analysts at a Another Hackathon


Noah S. - SDK Support Analyst
At Esri Technical Support, we enjoy working with JavaScript to create powerful web applications. I’d like to take this opportunity to share different ways of listening for events in our JavaScript API with On Style Events, which is the recommended pattern for event handling. As a previous blog focused on different patterns of event handling, this blog will stick with the best practices, tips, and tricks.

Note: Click images to enlarge.

The modular On Style Events (which means something like à la mode in French) are a bit different than Connect Style Events. Why does this matter? Because On Style Events are the recommended way to listen for and handle events with the ArcGIS JavaScript API. See the screenshot below for snippets of event styles.
on-style-event.png

Snippets of Event Styles



Since version 3.5 of the JavaScript API, these event handling functions receive a single event object from which all the event object properties can be accessed. Typically, this object is called event or evt in our samples. Instead of juggling multiple objects like with Connect Style, we can now dig into one object to access the information we need. There are two ways to use the On Style Events - with and without Dojo. The syntax for these event styles can be found in the JavaScript API reference. Let’s look at a couple code snippets to compare On Style Events with and without Dojo:on = with Dojo (on is an alias for the dojo/on module)
on(map, ’zoom-end’, function(evt) {
     console.log(evt.extent.xmin);
     console.log(evt.zoomFactor);
     console.log(evt.anchor.x);
     console.log(evt.level);
});
map.on = without Dojo (map.on means we can do this event ourselves)
map.on(’zoom-end’, function(evt) {
     console.log(evt.extent.xmin);
     console.log(evt.zoomFactor);
     console.log(evt.anchor.x);
     console.log(evt.level);
});

By examining the above code snippets, we can see that the main difference when using On Style Events is in what the event listeners return. We can also see similarities among the new styles of event handlers, but there are important differences worth exploring.

Not bad, right?

For more better understanding, here's a real-world example. You can follow along at home with the JavaScript Events application hosted on jsfiddle.net. Use the following instructions to follow along (I used Google Chrome for this example):

1. Open the application in your browser.

2. Press F12.

3. Navigate to the Console Tab, if not open already.

The following screen displays:
JSFiddle.png

JSFiddle



This application shows the functionality of dynamic layers and our elegant dark gray basemap tiles (you can also try the application live here: JavaScript Events application on GitHub). As you zoom in and out of the map, different layers become visible as indicated in the lower-left information box. There are six event listeners in this application. Let’s go through them one by one and see what they do.1) map.on("load", function()

When the map first loads, it immediately runs the unnamed function. This listener will only be called once while the application is running, and the listener does not take any arguments in the function. The purpose is to define the four other event listeners and to call the updateScale() function. This allows the scale to be defined in the information box without panning or zooming.2) map.on("zoom-end", updateScale)

After zooming in or out of a map, this event listener will call the updateScale() function. This function updates the map scale in the information box and in the Console tab. This listener does not take any arguments in the function, either.

See below for the event handler:
function updateScale() {
     dojo.byId("map-scale").innerHTML =
       dojo.number.format(parseInt(map.getScale()));
     console.log("Map scale: "
       + dojo.number.format(parseInt(map.getScale())));
}
3) map.on("pan-end", updateExtent)

When a user pans around the map, this event listener will call the updateExtent() function, which will update the map extent in the Console tab. This listener takes the generic evt argument in the function.Pro tip: There are many other attributes that you can dig out of the evt object. To see what is available, use the following steps (I used Google Chrome for this example):

1. Press F12 to open the developer's tools.

2. Navigate to the Source tab.

3. Find the section of code with this event handler (around line 170).

4. To set a breakpoint, click the line number to the left of the code.

See below for a screenshot of this process.
breakpointed.png

Breakpoint in Sources tab (Google Chrome)



5. Refresh the application, and when the application pauses on the breakpoint, switch to the Console tab and type “evt” into the prompt.

You can now expand the evt object to see what’s there and experiment with how to call it. View the screenshot below to see how the evt appears in the Google Chrome Console tab.
console_evt.png

evt in Console tab with Google Chrome



See below for the event handler:
 function updateExtent(evt) {
     console.log("Map extent");
     console.log(" XMin: " + evt.extent.xmin);
     console.log(" YMin: " + evt.extent.ymin);
     console.log(" XMax: " + evt.extent.xmax);
     console.log(" YMax: " + evt.extent.ymax);
}
4) map.on("zoom-start", updateOldLevel)

When a user zooms in or out of the map, as soon as the zooming action starts, this event listener will call the updateOldLevel() function. This updates the zoom level of the map in the Console tab. Again, the listener takes the generic evt argument in the function.

Please see below for the event handler:
function updateOldLevel(evt) {
     console.log("Map zoom level was: " + evt.level);
}
5) map.on("zoom-end", updateNewLevel)

When a user zooms in or out of the map, as soon as the zooming action stops, this event listener will call the updateNewLevel() function. This updates the zoom level of the map in the Console tab. Notice that it again takes the generic evt argument in the function.

Please see below for the event handler:
function updateNewLevel(evt) {
     console.log("Map zoom level is: " + evt.level);
}
6) usaLayer.on("load", load)

When the application first loads the usaLayer map service, this event listener calls the load() function, which displays the minScale values for each layer in the Console tab. If you open the map service from REST (http://sampleserver6.arcgisonline.com/arcgis/rest/services/Census/MapServer) and compare the minScale values for each layer, you see that the dynamicLayerInfo class in the code overrides each layer, which is pretty interesting. Notice that it again takes the generic evt argument in the function.

Please see below for the event handler:
function load (evt) {
     console.log("layer 1 minScale: "
       + evt.layer.dynamicLayerInfos[0].minScale);
     console.log("layer 2 minScale: "
       + evt.layer.dynamicLayerInfos[1].minScale);
     console.log("layer 3 minScale: "
       + evt.layer.dynamicLayerInfos[2].minScale);
     console.log("layer 4 minScale: "
       + evt.layer.dynamicLayerInfos[3].minScale);
}

For most of you, this is a refresher about working with On Style Events and the JavaScript API. But also for most of you, this will be new and exciting information to take your web apps (and salaries) to the next level. Let’s take a minute to review what we learned here. On Style Events have been around for a while and are slightly different than Connect Style, but are just as easy to use. On Style Events are simple and powerful ways of listening and handling many different event patterns. You can dig into all the arguments in the Console tab by setting a breakpoint and calling the argument object "evt".

Please consider reading our Concepts documentation for more information about working with events in the JavaScript API:https://developers.arcgis.com/javascript/jshelp/inside_events.html

Stay tuned until next time, when we discuss how to make your map "pop" with the new dojo.redecorate method. Happy eventing!
Noah S. - SDK Support Analyst
Outside of work, in my non-technical Clark Kent life, whenever I tell people about the Esri User Conference, the first thing they say is: “That doesn’t sound like any conference I’ve ever been to.” They typically follow that comment with something like: “What is GIS?” Over the years, I’ve been perfecting my responses to both of these statements, but I wanted to take this opportunity to truly do the topic justice.

First off, GIS is like post-modern cartography. What people once did with quills and sextants is now done on computers and in clouds. Actually, GIS probably began about one million years ago when early humans began to recognize the best hunting and gathering locations in their domain.

Second, the Esri User Conference is unlike any conference anyone has ever been to before… ever. It can be thought of in many ways - the best place for technical training, the ultimate spot for collaborative and networking opportunities, or, as my wife affectionately refers to it, GIS Gone Wild. I just call it awesome.
UC_con_2.jpg

San Diego Convention Center



Let's step back to 2012, when I was a young Student Assistant arriving in San Diego for the first time from graduate school in Chicago. I was one of 60 lucky students from around the world who were selected to attend and work at the conference. The Student Assistants are seen as the next generation of GIS, and Esri empowers them through this conference to connect with their future.

Understandably, this was one of the most amazing experiences of my life. I was overwhelmed by the excitement and knowledge of so many GIS professionals converging in one place. I don’t think my feet touched the ground all week. We were all on the same level, gorging on new technologies, meeting with new people, and buzzing through the exhibit halls and corridors in a constant state of GIS euphoria. Putting faces to names; learning how products worked; seeing what are going to be the next big things in the industry - the smile never left my face.

Fast forward to 2014, where I am a proud Esri employee working in Support Services, and I once again attend the User Conference. This time, I arrive as a staff member working with the Student Assistants. I am so excited for them. I remember what this conference meant to me then, and it still means the same to me now. Even as I write these words, I am glancing at the calendar, marking off the days until next year’s conference.
StudAssistants2014.jpg

2014 Esri Student Assistants



This year’s group of students are as strong and promising as I remember my group being. They are hungry, curious, and (relatively speaking) young. I try to explain how amazing this opportunity is for them at the User Conference, both personally and professionally. Luckily for them, I’m not the only Esri staff member on hand. We have an incredible team that works with the students. Terri B. has been working with the Student Assistants for five years, and has been at Esri for over 20 years. Terri probably knows everyone by name and is liked by every single Esri employee.Pete H. is one of the nicest and most sincere human beings I’ve ever met, not to mention extremely competent. Melissa Q. is new to the team, but threw herself into the mix with the same interest and excitement that I felt two short years ago. Michael J. works on the HR side in recruitment, and is a tireless “miracle worker” who ensures that high-caliber students are brought into our professional family. Matt P. is a fellow Support Analyst and veteran User Conference student leader, whose sharp dress and quick wit are surpassed only by his critical thinking and managerial abilities. And me? I just feel grateful to have the chance to work with these amazing people.
2014-uc-staff2.jpg

2014 Esri UC Student Assistant Staff with Monte



Now back to our regularly scheduled blog post, where people who have never attended the conference have trouble understanding what it feels like to be there. There are three main reasons that the Esri User Conference stands apart from other conferences. The first reason is the location of the conference. San Diego is a beautiful city full of unique attractions, great food, and great weather. In one day you can attend a technical workshop, get your picture taken with Jack Dangermond, grab a coffee, go to the beach, tour an aircraft carrier, grab another coffee on your way to catch a baseball game, and then meet up with your colleagues at one of the many fabulous restaurants and/or bars. And, if you brought your passport, you can even spend an afternoon in Mexico using public transportation.

The second reason, which is even more important than easy-breezy San Diego, is Esri. I wrote a blog post back in the day about what it feels like to work at Esri, and that feeling has remained unchanged after 1.5 years. Forget about the fact that I love GIS, and that Esri is all about GIS. Forget about the fact that I get to live in a mountain community with snow and bears and I can still carpool to work with my wife every day. Forget about the fact that I am constantly challenged with and trained on the latest and greatest technologies - both hardware and software. The truth remains that Esri has attracted and retained some of the most amazing people I have ever had the pleasure of working with in my life. It is these same people that come to the conference. They work, they present, they socialize. They make this conference amazing.
stud_dinner.jpg

Amazing Student Assistants at Dinner



However, better than Esri, cooler than San Diego, and undoubtedly the best part of the conference… is you. The customer, the presenter, the collaborator, the vendor - even the family and friends that come with you and hang out at the pool or Kids Camp during the conference. I met and talked with you in sessions, in line at Starbucks, in the Exhibit Hall, in the elevator, then again at the bars. We sat on the floor at Registration and watched the World Cup together. We held doors open and gave directions to each other. We laughed and ate tasty food together in the Map Gallery. There was so much joy and camaraderie in you all. This is the magic beyond planning and plenaries. This is the feeling that is greater than the sum of every button worn or selfie taken. This is why no one has ever been to a conference like the User Conference.

Now the conference is over. In this rare quiet moment, after I leave San Diego and return to my haven in the mountains, I sit and reflect on what the conference looked like through the eyes of the Student Assistants. To be honest, it’s very much the same as what you and I experienced. It’s like the first years of college or summer camp, when everything is new and possible, and everyone can be your friend. It’s like the best thing ever. I hope to share this experience with you again next year.

Until then, let's get some rest.
fun_students2.jpg

Bannerstands, with the Student Assistants

For more information on the Esri User Conference Student Assistantship Program, see: http://www.esri.com/careers/students/user-conference-student-assistants


Noah S. - SDK Support Analyst

This blog post is the first in a series of debugging tips and tricks to help you on your way. 

It’s a jungle out there. And like it or not, it’s a jungle inside your application as well. Working through the bugs isn’t as simple as slowly sifting through lines of code; it takes dedicated tools and candid curiosity. In the jungle, the momma gorilla has little more to rely upon than her courage and her cunning. But as a web developer, you have a variety of tools at your disposal.  Today, we are going to take a look at the Network tab inside Google Chrome’s Developer Tools.

Accessing the Chrome Developer Tools is easily done using shortcut keys (Control + Shift + I) or by navigating to the top right of the browser, clicking on the three grey horizontal lines, then choosing “Tools”, then “Developer tools”.three_grey_lines4.png

Unlike the momma gorilla, Chrome Developer Tools cares about you and your applications. It likes you. It thinks you’re a really good developer. But you need to do some work. It’s kind of like Esri Support. We like you. We want to help you, and we’ll be there when you take the first step.

While the developer tools are open, you can clear the browser cache by simply clicking and holding the refresh button.  This action presents you with three different options: Normal Reload, Hard Reload, and Empty Cache and Hard Reload. These options help you ensure that changes to your code are reflected in the browser. Otherwise, the application may load the older code from the browser’s cache. When I’m feeling blue, a couple of Hard Reloads always does the trick. If it’s near the end of the day, you may want to empty the cache first. 3_reload.png

Now that you’ve cleared the cache and reloaded your application, we can continue.  Like the developer tools in other major browsers, such as Firebug, and standalone tools like Fiddler, the Network tab in Chrome logs individual requests spawned from the tab currently open in the browser.  Typically, a variety of resources are loaded when a page is refreshed and additional requests are executed while the user is interacting with the page.

The Network tab is my personal favorite. I always open this tab before running any test application. Here we can focus on inspecting web traffic to discover how the application interacts with online services. If there is a print service in the application, you can grab the webmap as JSON in the network tab, and compare it’s parameters against the REST API to see if the JSON is valid. You could also see all the resources the application is consuming, and where those resources are located.

If something has gone visibly wrong in the application, the first things to look for are requests that have failed entirely.  The most common errors are a 403, indicating that you don’t have permission to access the resource, and 404, which means the resource can’t be found.  In my own experience, 404 errors are most often caused by a typo I introduced when I wrote out the location of a service, because I write code like a momma gorilla.

converted.jpg

This screenshot shows the Network tab open with a 404 error (Not Found) in the network traffic regarding a missing .css file on the server named localhost (I put the .css in the wrong folder)


In this installment, we learned how to access and use the Network tab inside Chrome Developer tools to reveal the individual requests launched by an application, and their success or failure. This information can greatly facilitate the debugging of an application when minimal other error information is available by indicating to the developer what is occuring behind the scenes, and on what areas in the code to place focus. This concludes part one of a multi-part series on JavaScript Debugging Tips. Join us next time when we delve even deeper into the Network tab with a real-world example. Happy debugging!

NSager-esristaff

Supporting Cast

Posted by NSager-esristaff Employee Jun 26, 2013
Before I came to Esri, my mental image of technical support was of a few brainy analysts hunkered down in front of bright monitors on top of cluttered desks, strewn with cables and soda cans, happily clicking away down dark corridors in dimly lit offices. I imagined this was a department of autonomous people who knew everything, and the only limiting reagent to helping clients was the amount of time required to explain, and then implement the solution. This is much the same way I view car mechanics; when I have a problem, just describing the funny noises my car makes should suffice for them to diagnose and get started on the repairs. Turns out, I’m wrong.

noah_geo_small1-300x225.jpg

I started at Esri a few weeks ago. With the right technical baseline, they told me they can train anyone who has the curiosity and communication skills to make a good Support Analyst. I was assigned a mentor, a manager, a technical manager, and a few other people who would fill out the supporting cast. Their objectives were to get me used to the company culture and show me where to go for help. Collaboration is a huge part of Support culture, and no analyst is an island. I was not expected to know everything, but I was expected to be able to handle anything. Soon, I will begin as an active Support Analyst.

The cast of analysts I am joining in Support is one of the most diverse groups of people I have ever encountered in my professional life. They run the gamete in almost every possible category. Yet, even with so many differences, what unifies people here is an almost palpable sense of curiosity. You can feel it when you walk around the offices. The amount of knowledge people have here is staggering, but what people don’t know -- what people have to research and learn and test and then translate into digestible words and instructions to help a user along their way -- is truly astonishing. It would be impossible for any one analyst to know everything about every product and service that Esri supports, so what makes for a good Support analyst is the curiosity to want to learn, and the ability to help others understand.

My mentor, John, is a perfect example. He started working in Support on the Desktop team before moving over to SDK because he was fascinated by programming. With that strong desire to learn and to grow as an analyst, he quickly became a top-notch SDK Support Analyst and genuinely enjoys his work. Now he mentors new analysts in addition to his normal duties, his passion and curiosity make him a natural teacher. This is what motivates people like John, like the people found in Support. We do not offer pre-packaged answers to the infinite variety of potential issues our users face, but rather treat every user issue as a new opportunity to gain and to share knowledge. The Support Analyst has a fierce intellect combined with an insatiable appetite to learn and to help.

This is not meant as a commercial or advertisement, but I am a new analyst in training and interacting with dozens of people every day who are interested in the company and the products we support. Perhaps I come from a world where my professional interests were shared by a small minority of people, so I feel a little starry-eyed. Now, I find myself in Support, happily clicking away along breezy corridors in brightly lit offices, surrounded by a curious cast of characters, like me.Noah S. - SDK Support Analyst

Filter Blog

By date: By tag: