profile
viewpoint

rigdern/react-winjs 15

React wrapper around WinJS's controls

jennifermarsman/TweetDVR 5

Using Azure's big data capabilities, we grab a tweet stream for a show and then you can watch the twitter stream as it was in realtime when you are watching a DVRed show.

rigdern/typescript-to-externs 2

A command line tool which converts TypeScript type definition files to externs files for use with the Google Closure Compiler.

rigdern/react-native-sqlite-storage 1

Full featured SQLite3 Native Plugin for React Native (Android and iOS)

phosphoer/winjs-store 0

A sample WinJS app

rigdern/angular-winjs 0

Project to smooth the AngularJS/WinJS interaction

rigdern/cdnjs 0

Our goal is to operate this CDN in a peer reviewed fashion.

rigdern/css-layout 0

Reimplementation of CSS layout using pure JavaScript

pull request commentmicrosoft/react-native-experimental-navigation

Alter react lifecycle methods to match current deprecation

I just gave @erictraut permissions to the repo.

Also, if we need a Skype contact, @danmuresan is a current Skype engineer with access to Skype's open source repos.

mikehardy

comment created time in a month

issue openedMicrosoftDocs/azure-docs

Unclear wording: "certificate with the furthest into the future expiring certificate"

It seems like the wrong word is used in the following sentence from the "Node-to-node certificate security" section:

Service Fabric SDK's default behavior is to deploy and install the certificate with the furthest into the future expiring certificate;

Specifically, I think "furthest into the future expiring certificate" should be "furthest into the future expiring date" similar to the phrase shown later in the paragraph.


Document Details

Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

created time in 2 months

issue commentMicrosoftDocs/azure-docs

Elaborate on warning about attempting to read from files on the Consumption plan

@craigshoemaker Thanks for the response. I believe this issue should be reopened. Let me elaborate on my feedback.

the guidance of what to do instead is to use the options and settings as described in the section above the warning

The section above the warning just talks about putting settings in local.settings.json and provides a link to the app settings doc with little additional context. This section makes sense if you are already experienced with Azure Function settings. If you are not, this section is cryptic because it's missing context.

Imagine being new to Azure Functions and coming across this doc page. After reading this section, I would have these questions:

  • I'm confused, am I supposed to use local.settings.json or not? The section had an example using local.settings.json but then a warning mentioned I shouldn't use local.settings.json. Maybe local.settings.json is only for the Premium and Dedicated plans.
  • The warning also mentions that I can't read from appsettings.{environment}.json. That's how I store my settings in my .NET core web service. If I can't store my settings there in an Azure Function, where am I supposed to store them?
  • The section mentioned this app settings doc in passing but didn't reference it at all in the example. What is its relationship to the rest of the section?

Being experienced with Azure Function settings, I can tell you a big concept that's missing is explicitly calling out the distinct mechanisms for managing settings for local deployments (local.settings.json) and Azure deployments (Application Settings in the Azure Portal). I filed #55976 to call out this and other topics that I think should be included in an overview doc about Azure Function settings. Perhaps this section should link to such an overview doc.

As for why I call out Consumption specifically - values read from those .json files aren't available as the app scales because the hosting infrastructure has no access to the configuration information as its spinning up additional instances of the app.

Why doesn't this apply to the Premium plan? If it's okay to read files in the Premium and Dedicated plans, perhaps it's worthwhile to call that out explicitly so developers don't have any doubts in their minds.

rigdern

comment created time in 2 months

issue openedMicrosoftDocs/azure-docs

Overview doc about Azure Function settings

There should be a doc that gives an overview about settings in Azure Functions that covers these topics:

  • The distinction between settings for local deployments (local.settings.json) and Azure deployments (Application Settings in the Azure Portal). They use different settings mechanisms.
  • How Azure Function settings compare with .NET core web services settings. Currently, developers like me wonder "I configure my .NET core web service with appsettings.json and appsettings.<environement>.json. Can I do the same with my Azure Function?".
  • Describe how objects need to be flattened (e.g. { "Foo": { "Bar": 2 } } becomes { "Foo:Bar": 2 })
  • Describe how arrays need to be flattened (e.g. { "Foo": [2] } becomes { "Foo:0": 2 })

See issue #39109 for additional suggestions about what kind of information is missing from the current settings docs.

After reading this new doc, I'll still be left with questions specific to settings for local deployments and Azure deployments.

Settings for local deployments

  • Should local settings (local.settings.json) be checked into git? local.settings.json is in the default .gitignore which leads me to believe I shouldn't check it in. If that's the case, how do we share the settings amongst members of our team?
  • Is the @ KeyVault syntax supported in local settings? If not, what should I do instead? There's an unanswered GitHub issue about this

Settings for Azure deployments

  • Can I manage my settings for Azure deployments in git? I'd like them to be version controlled. It seems like I can't because they are managed through the Azure Portal.

Document Details

Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

created time in 2 months

issue openedMicrosoftDocs/azure-docs

Elaborate on warning about attempting to read from files on the Consumption plan

There's a warning at the bottom of the "Working with options and settings" section

Avoid attempting to read values from files like local.settings.json or appsettings.{environment}.json on the Consumption plan. Values read from these files related to trigger connections aren't available as the app scales because the hosting infrastructure has no access to the configuration information.

This leaves me with 2 questions:

  • If I can't read from those files, what should I do instead?
  • What is special about the Consumption plan that prevents this from working? Or does this warning also apply to the Premium and/or Dedicated plans?

Document Details

Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

created time in 2 months

issue openedMicrosoftDocs/azure-docs

Structure of "Avoid long running functions" section is confusing

I found it very difficult and time consuming to understand the content of the "Avoid long running functions" section. Part of the difficulty comes from each paragraph being about a very different topic and there not being smooth transitions between the paragraphs. See below for comments about each paragraph.

Paragraph 1

Feedback:

  • The phrase "timeout issues" is ambiguous. Does it mean that the Azure Function's outgoing requests might timeout if the Function is long running? Or is it referring to the Azure Function itself timing out?
  • It's not clear enough that Azure Functions have a time limit associated with them because it's not explicitly stated.
  • "issues" in the phrase "timeout issues" makes it sound like "timeout issues" might be a bug rather than the Azure infrastructure functioning as intended.

Here's an example of how the first paragraph could be written to avoid those issues:

> Azure Functions have a time limit. If they exceed this time limit, they will be killed by Azure. The specific time limit depends on the Azure Function plan. See function app timeout duration for more details.

Paragraph 2

From reading the first sentence of paragraph 2 ("A function can become large because of many Node.js dependencies."), it's unclear how the paragraph relates to the section "Avoid long running functions". The relationship between this paragraph and the section "Avoid long running functions" is that it is describing one thing that could cause your Function to run for a long time. The first sentence of the paragraph should call out this relationship explicitly to make it easier for readers to understand the paragraph.

Paragraph 3

Feedback:

  • The first sentence of the paragraph implies that it is about "refactor[ing] large functions into smaller function sets". However, that's not what the example in the paragraph is about. The example seems to transition from a solution with one Azure Function to a solution with two Azure Functions where one Azure Function will still run for about the same amount of time as the Function from the original solution.
  • This paragraph seems to state that you can avoid a "long running" Azure Function by having the Function queue the work and return immediately. Then a queue-triggered Function can execute the work. This is confusing because the solution still seems to involve a "long running" Azure Function.

Ideas for a better structure for the section

You might consider structuring the section like this to make it easier to follow:

  • Issues long running Azure Functions can run into
    • Describe how Azure Functions have a time limit
    • Describe how some triggers such as webhooks and HTTP triggers require an acknowledgment response within a certain time limit
    • Describe any other issues an Azure Function may run into if it's long running
  • Techniques for avoiding long running Azure Functions
    • Describe techniques such as having the Azure Function place work onto a queue and then return. You should also describe how the queue can be consumed without the consumer running into issues associated with long running Azure Functions.
  • Factors that can cause your Azure Function to run for a long time
    • Describe the Node.js dependency stuff from the second paragraph
  • If you really need a long running Azure Function
    • Describe valid scenarios for long running Azure Functions (if any)
    • Mention other Azure components a developer should consider using rather than an Azure Function to implement their long running task
    • Guidance for implementing a long running Azure Function (e.g. pick the right plan and set AlwaysOn)

Document Details

Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

created time in 3 months

issue openedMicrosoftDocs/azure-docs

Elaborate on guidance "Avoid long running functions"

I'm considering using an Azure Function in a scenario that I suspect is "long running." After reading the section "Avoid long running functions" I still have these questions:

  • How long is considered to be "long running"? The reader might have a different interpretation of "long running" than the Azure team.
  • Is there ever a valid situation to have a "long running" Azure Function? If yes, what are the situations and are there any gotchas?
  • If my use case involves a "long running" function, what should I do? Is there some other Azure component I should be using instead of an Azure Function?

Document Details

Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

created time in 3 months

issue commentMicrosoftDocs/azure-docs

Include a section about how to run an Azure Function on-demand via the Azure Portal

@DixitArora-MSFT I believe this issue should be reopened. My suggestion is about the doc page Manually run a non HTTP-triggered Azure Functions. I retitled my issue to clarify my suggestion.

My suggestion is to describe how to run an Azure Function on-demand via the Azure Portal. This is very useful for non HTTP-triggered Azure Functions. This is how you do it:

  • Go to the "Code + Test" page in the Azure Portal
  • Click the "Test" button

This doc page (Manually run a non HTTP-triggered Azure Functions) currently only describes how to run an Azure Function on-demand via Postman.

rigdern

comment created time in 3 months

issue commentMicrosoftDocs/azure-docs

How do I trigger my function on-demand so I can test it?

@DixitArora-MSFT I believe this issue should be reopened.

My feedback was about the page Timer trigger for Azure Functions.

My suggestion is that the page Timer trigger for Azure Functions should link to Manually run a non HTTP-triggered function. This will make it easier for developers to find this information.

Rationale for My Suggestion

This suggestion comes from a pain point in my personal experience using Azure Functions. I thoroughly read the doc pages related to the Timer trigger trying to figure out how to run them on-demand. I couldn't figure it out. It was only days later that I accidentally came across the doc page Manually run a non HTTP-triggered function. I believe my suggested doc change will save future developers from experiencing this pain point.

rigdern

comment created time in 3 months

issue commentMicrosoftDocs/azure-docs

Time zone for Azure Functions deployed locally

@DixitArora-MSFT I believe the issue should be repoened. Let me clarify why. There are two different deployment scenarios:

  1. Deploying an Function to your local machine
  2. Deploying a Function to Azure

The information you posted and the documentation page are only accurate for (2) deploying a Function to Azure.

They are not accurate for (1) deploying a Function to your local machine. See my original post above for a description of the behavior I observed for (1).

I can think of two possible fixes:

  • The ideal fix would be to update the Azure Function implementation so that time zones behave the same way regardless of whether they've been deployed to Azure or your local machine.
  • The second best fix would be for the documentation to be updated to describe the behavior for both deployment scenarios.
rigdern

comment created time in 3 months

issue openedMicrosoftDocs/azure-docs

Time zone for Azure Functions deployed locally

From experimentation, it seems that the time zone behavior is different based on whether a Function is deployed locally or to Azure. The time zone behavior described on this doc page is only accurate for Functions deployed to Azure.

This doc page should be updated to cover the time zone behavior for Azure Functions deployed locally. My understanding is that the time zone is always the local time zone and the WEBSITE_TIME_ZONE Application Setting is ignored.

Ideally, the implementation would be updated so that the time zone behavior is the same regardless of whether the Function was deployed locally or to Azure.


Document Details

Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

created time in 3 months

issue openedMicrosoftDocs/azure-docs

What is a valid use case for `runOnStartup`?

What is runOnStartup designed for? What's a valid scenario for using it? This page currently only lists reasons you wouldn't want to use runOnStartup.

If I'm considering using runOnStartup for some scenario, the current docs make it difficult to know whether it's a good idea and matches the intent behind runOnStartup.

Adam Comella Microsoft Corp.


Document Details

Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

created time in 3 months

issue openedMicrosoftDocs/azure-docs

Where is the reference documentation for `TimerInfo`?

I'm interested in seeing the reference documentation so I can learn more about the semantics of TimerInfo's properties. However, this documentation currently doesn't appear to exist. Here are the dead ends developers run into due to the current state of things:

  • Poor results when using search engines to search for TimerInfo
  • Using "Go to Definition" on TimerInfo in Visual Studio reveals TimerInfo's declaration. However, the doc comments are missing so it doesn't reveal any insights.

This page gives insights about TimerInfo by linking to its source code but that solution isn't ideal for the reasons listed above.

Adam Comella Microsoft Corp.


Document Details

Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

created time in 3 months

issue openedMicrosoftDocs/azure-docs

Include a section about how to do this via the Azure Portal

The Azure Portal has a "Code + Test" page that enables you to run Azure Functions on-demand. It would be helpful to include a section about that on this doc page.

Adam Comella Microsoft Corp.


Document Details

Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

created time in 3 months

issue openedMicrosoftDocs/azure-docs

How do I trigger my function on-demand so I can test it?

When testing, it's inconvenient to wait for the timer to trigger. How can I trigger the function on-demand? It would be nice for the documentation to cover this for both local deployments and Azure deployments.

For functions deployed in Azure, from a lot of searching, I learned that this can be done on the "Code + Test" page for the Azure Function.

Adam Comella Microsoft Corp.


Document Details

Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

created time in 3 months

more