As I understand the documentation and example with this setting
autoScalingGroup.scaleOnMetric('ScaleToCPU', {
metric: workerUtilizationMetric,
scalingSteps: [
{ upper: 10, change: -1 },
{ lower: 50, change: +1 },
{ lower: 70, change: +3 },
],
// Change this to AdjustmentType.PERCENT_CHANGE_IN_CAPACITY to interpret the
// 'change' numbers before as percentages instead of capacity counts.
adjustmentType: autoscaling.AdjustmentType.CHANGE_IN_CAPACITY,
});
you will have the downscaling alarm (with upper bound 10%) permanently in state "In Alarm" when you reached the minimum number of instances and use less of 10% CPU, right?
I read this SO post and it is suggesting the exact same: make the Action to switch to state "Ok".
Moreover, with this CDK construct we don't have any chance to do anything from the comment section of the above mentioned SO post.
So, I just wanted to confirm that this permanent "In Alarm" state in our Cloudwatch console is the intended situation.
Related
I would like to automatically bulk delete all tasks older than a month in HubSpot (we have more than 10,000 tasks!), instead of doing it one by one. I tried looking on the internet but it doesn’t seem that HubSpot has any functionalities like it. Thus, I tried to implement such scenario using Make (formerly Integromat) unsuccessfully.
Answering to my question for knowledge purposes.
I managed to create a scenario allowing me to automatically bulk delete tasks (or anything) based on a certain set of criteria using Make (formerly Integromat). I had to use HubSpot’s API and Flow Control tools to achieve such result.
The scenario looks like the following:
Module 1: API Call
Search for all tasks based on a certain set of criteria (here, all tasks created before the last 30 days).
If you wish to search for another object (such as contacts or deals), you can take a look at the CRM Search API for all available search requests. You can also browse through the Properties API to get a comprehensive list of available properties.
URL: /crm/v3/objects/tasks/search
Method: POST
Body:
{
"limit": "5",
"properties": [
"hs_task_subject",
"hs_task_type",
"hs_timestamp"
],
"filterGroups": [
{
"filters": [
{
"propertyName": "hs_task_status",
"operator": "EQ",
"value": "NOT_STARTED"
},
{
"propertyName": "hs_createdate",
"operator": "LT",
"value": "{{formatDate(addDays(now; -30); "x")}}"
}
]
}
]
}
Module 2: Repeater
Initial Value: 0
Repeats: {{if(module1.body.total = null; 1; module1.body.total / 100)}} (if total is less than 100, do not repeat)
Step: {{ifempty(module1.body.paging.next.after; 100)}} (automatically sets it to the first module’s after value, otherwise to 100 if after` value is empty)
You can find out more about properties and search limitations here and here. Basically, the repeater allows you to loop over all HubSpot pages.
Module 3: Sleep
Sleep module to prevent RateLimitError
Module 4: API Call
Same as Module 1, except that you must add an after parameter to include the repeater’s value.
+ "after": "{{module2.i}}"
Module 5: Iterator
Iterate over Module 4’s results array: {{module4.body.results}}.
Module 6: API Call
Delete tasks using the ID returned by the iterator.
{
"inputs":[
{
"id":"{{module5.id}}"
}
]
}
Voilà !
Performing two quick "switch toggles" causes a flicker because React-Native Switch updates the UI for second-switch element before Firestore DB completes the first switch update.
I have a collection of tasks, where each task has the following schema:
task : {
shared: {
sample_user_id_1: true,
sample_user_id_2: false
}
}
Because Firestore returns a full document snapshot (and not just a specific part of document that was updated), I see two solutions here to remove the flicker:
1) Only dispatch & pipe the change that was updated, essentially only listening to part of the document at a time (dispatch a state change independent of Redux-Firestore) eg:
if(newValue.shared[user_id_1] !== oldState.shared[user_id_1])
dispatch(manualShareUpdate(user_id_1));
This solution does not seem scalable.
2) Change Data structure such that each "shared" bit is stored independently of other shared bits eg.
task : {
id: task_1
}
New "task_shared" collection for each task, shared pair
task_shared : {
task_id: sample_task_id
user_id: sample_user_id,
shared: true
}
I'm using mauron85 Backgroundgeolocation plugin for my ionic 3 application.
It works, the only problem is the timing when it engage.
The problem is even if I subscribe and start the plugin, it engage only after a couple of minutes.
Namely it returns the position in the moment that I start it, but before engaging and actively tracking it takes some time.
Also sometime when I put the app in background it does not start recording.
That is the code I used:
import { BackgroundGeolocation, BackgroundGeolocationConfig, BackgroundGeolocationResponse } from '#ionic-native/background-geolocation';
Then the consifugration and start:
let config: BackgroundGeolocationConfig = {
locationProvider: 0,
desiredAccuracy: 10,
stationaryRadius: 1,
distanceFilter: 1,
activitiesInterval: 100,
interval: 1000,
notificationTitle: 'TiCaccio is tracking you',
notificationText: 'you know it, right?'
// debug: true
};
this.backgroundGeolocation.configure(config).subscribe((location: BackgroundGeolocationResponse) => {
console.log("Background location", location);
this.lat = location.latitude;
this.lng = location.longitude;
});
this.backgroundGeolocation.start();
Now the problem is in fact that sometimes it engage, sometimes not. And even when it engage it just do that after a couple of minutes.
I am not sure how best to utilize the edge weight (e.g. strength of interaction between two interacting proteins) while generating a force directed layout using the CoSE plugin in cytoscape.js. Could someone provide any pointers. Should it be "idealEdgeLength" or "edgeElasticity"?
(EDIT) Following is a figure showing what I currently get (A) and what I am trying to achieve (B). Also below are the parameters I used for generating the layout.
Thanks,
Datta.
PS: Click to view a figure showing the current (labelled "A") and expected (labelled "B") layouts. Following are layout options for "A".
var options = {
name: 'cose',
// Called on `layoutready`
ready: function () { },
// Called on `layoutstop`
stop: function () { },
// Whether to animate while running the layout
animate: true,
// Number of iterations between consecutive screen positions update (0 -> only updated on the end)
refresh: 20,
// Whether to fit the network view after when done
fit: true,
// Padding on fit
padding: 30,
// Constrain layout bounds; { x1, y1, x2, y2 } or { x1, y1, w, h }
boundingBox: undefined,
componentSpacing: 100,
// Whether to randomize node positions on the beginning
randomize: true,
// Whether to use the JS console to print debug messages
debug: false,
// Node repulsion (non overlapping) multiplier
nodeRepulsion: 400000,
// Node repulsion (overlapping) multiplier
nodeOverlap: 10,
// Ideal edge (non nested) length
idealEdgeLength: 10,
// Divisor to compute edge forces
edgeElasticity: 100,
// Nesting factor (multiplier) to compute ideal edge length for nested edges
nestingFactor: 5,
// Gravity force (constant)
gravity: 80,
// Maximum number of iterations to perform
numIter: 10000,
// Initial temperature (maximum node displacement)
initialTemp: 100,
// Cooling factor (how the temperature is reduced between consecutive iterations
coolingFactor: 0.95,
// Lower temperature threshold (below this point the layout will end)
minTemp: 1.0
};
You can specify functions instead of static numbers for some key CoSE layout settings. The functions take edges (or nodes, in some cases), so you can tailor the layout based on edge properties.
So you could do something like this:
idealEdgeLength: function (edge) {
// Default is: 10
// Instead, base it on "weight"
return edge.data().weight * .5
},
edgeElasticity: function (edge) {
// Default is: 100
// Instead, base it on "weight"
return edge.data().weight * 4
},
You'll have to experiment with ranges that work with the layout engine and the range of weight you are expecting as input, but that approach should work AOK.
The ideal edge length specifies a default-like value, whereas the elasticity specifies one of the forces that determine the final length. In general for physics simulation layouts, you will need to experiment with different values and evaluate the results for your specific graphs.
If I POST an issue transition like this:
{
"fields" : {
"resolution" : {
"name" : "Fixed"
}
}
}
...I get this error:
{
"errorMessages" : ["Missing 'transition' identifier"],
"errors" : {}
}
This seems to imply that I need to include a transition ID along with my list of changed fields. https://stackoverflow.com/a/14642966/565869 seems to say the same. Fine.
However, transition IDs appear to be global. It's not enough to look up the highest transition ID for this issue and increment it; such an ID is probably in use elsewhere. At some expense, I could get the highest transaction ID used anywhere in the system; this might be 68,000 at this moment. But if I were then to use transaction ID 68,001 there's a real chance that a GUI user would attempt a transition of their own and use this ID before I could.
I could use transaction IDs in the range of 1,000,001 and up, but if the JIRA web GUI uses the highest previously used transaction ID when generating new IDs I'll just collide in this range instead of the 68,000 range. I could use 69,000 and trust that there won't be a thousand transitions in the length of time it takes to get the highest transaction ID.
These both seem terribly clumsy, however. Is there no way to post a transition and let JIRA generate its own unique ID? I don't need to retrieve the generated IDs, I just want to update issues' statuses and resolutions.
You're getting mixed up a bit. So lets see if I can explain it better for you.
To transition a JIRA Issue, you use the Transition ID to identify what transition to apply to the issue. You aren't specifying an ID for a transaction or a transition ID to identify that the transition occurred, JIRA takes care of this for you.
The easiest way to understand it is to see it.
So first you can look at what transitions are available to an Issue by doing a GET to the API Call:
/rest/api/2/issue/${issueIdOrKey}/transitions
Example:
/rest/api/2/issue/ABC-123/transitions
Which will show something like this:
{
"expand": "transitions",
"transitions": [
{
"id": "161",
"name": "Resolve",
"to": {
"description": "A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.",
"iconUrl": "https://localhost:8080/images/icons/statuses/resolved.png",
"id": "5",
"name": "Resolved",
"self": "https://localhost:8080/rest/api/2/status/5"
}
}
]
}
So you can see only 1 transition is available for issue ABC-123 and it has an ID of 161.
If you were to browse to that JIRA Issue through the GUI, you would see only 1 Transition available and it would match the API Call. In fact if you inspected the element you should see it having an a tag and in the href something like action=161
So should you want to transition this issue, you'll need to do a POST to the following URL:
/rest/api/2/issue/ABC-123/transitions
With JSON like this:
{
"update": {
"comment": [
{
"add": {
"body": "Bug has been fixed."
}
}
]
},
"fields": {
"assignee": {
"name": "bob"
},
"resolution": {
"name": "Fixed"
}
},
"transition": {
"id": "161"
}
}
Which uses the transition ID found from the call that shows all transitions. I also update the resolution and assignee and add comments at the same time.
That make a bit more sense?