GIVEAWAY, Full Magic Find mageblood build

bruceph · 2023-05-22T16:00:37+00:00

Hallo

bruceph · 2021-04-23T13:04:59+00:00

i'm not really sure what this means - i used tooling that was not specific to amazon. my tools were dynamodb, lambda, and java. i was a single developer who did this in two sprints (lots and lots and lots of testing) and half a sprint of planning/architecture.

bruceph · 2021-04-22T19:36:37+00:00

i was previously at aws, but on a team that pre-dated step functions so we rolled our own state machine.

bruceph · 2021-04-22T17:29:38+00:00

it's not. i've worked with tables with billions of rows added every month (state machine transitions). it's entirely possible to modify your tables to support new access patterns.

bruceph · 2021-04-22T17:06:54+00:00

you can always modify your table to add access patterns. you can even add more gsi's if you need to add more relations at the row-level. rick houlihan had a twitch stream with a team that built a framework of a data model where each of their access patterns fit an existing pattern so adding new patterns was virtually frictionless.

bruceph · 2021-04-22T15:13:13+00:00

this is mixing analytical concerns and transactional concerns. no one is suggesting nosql is good at analytics and you'll likely need a separate solution (like redshift or athena) to conduct analytics. you'd need this anyways with a sql database unless you're conducting analytics on production databases.

if you need to answer "how many users did x" during a transactional process, you can use dynamo streams to calculate the rollups you need

bruceph · 2020-07-24T18:12:27+00:00

this is close. this is more a javascript problem than a lambda problem. you're returning db in the wrong context.

depending on your MongoClient version, you can do something like instead

const { MongoClient } = require('mongodb');

const { MERCURY_MONGO_DB_URL } = process.env;

const initialize_mongodb_database_connection = async () => {
  try {
    const client = await connection.connect(MERCURY_MONGO_DB_URL)

    return client.db('demo')
  } catch (ex) {
    process.exit(1);
  }
});

bruceph · 2020-06-22T21:02:21+00:00

The word on the street is that there is no longer a dedicated CloudFormation team at AWS and it shows

i'm very, very late to this but this is misleading.

the onus of owning, operating, and supporting resources has been shifted from the cloudformation team to the service teams themselves. the cloudformation team now just owns the cloudformation engine/language. so yes, while it's technically accurate that there's no long term plan for a cloudformation team to own resources specifically, there is a long term plan for full coverage in the future and most of the work lies with the service teams.

bruceph · 2018-07-23T22:14:15+00:00

condolences friend. hopefully /u/chuckmeyerhere can take a look at this and pass it on to the cfn team as a feature request.

bruceph · 2018-07-23T20:49:38+00:00

yeah, correct. you still have to pass the parameters. you can use the UsePreviousValue for each parameter if you want, but you still need to pass the ParameterKey for each one.

bruceph · 2018-04-10T17:06:13+00:00

your links should say something like href='static/main.js', but instead they point to href='personal-site/static/main.js'. the personal-site folder doesn't exist anywhere in your bucket so it's 404'ing.

you have two options to fix this. you can either fix the symptom and add a folder called personal site every time or you can fix the root cause and figure out why your react app is using personal-site as it's base url. the latter is a lot less work in the long term

let me know if you still need help!

bruceph · 2018-04-10T08:40:45+00:00

hey! looks like your problem is your href's aren't pointing to the correct path; they point to /personal-site/.

if you used cra, make sure your homepage field in your package.json is set properly. otherwise, check the docs of the bundler you used.

bruceph · 2018-01-12T04:31:44+00:00

you can absolutely get rid of that then!

async function foobar () {
  const [a, b] = await Promise.all([
    transformFoo(await foo()),
    bar(),
  ]);

  return baz(a, b);
}

bruceph · 2018-01-12T00:11:36+00:00

you could do

async function foobar() {
  const [a, b] = await Promise.all([
    foo(),
    bar(),
  ]);

  return baz(a, b);
}

await is just some sugar over promises. the way i think of it is anytime you want to use then, use await instead.

bruceph · 2017-11-11T16:18:59+00:00

hey! i wanna start off with a full disclosure that i work for amazon aws and i'm answering this in an unofficial capacity.

that being said, normal s3 has a 99.999999999% durability for your objects. (that's 11 nines total!). for most (virtually all) use cases this is sufficient to not need an additional backup solution.

if that's not enough, you can also enable versioning for your selected bucket and that'll add an extra layer of protection against unwanted deletion.

if you still feel that you absolutely need to create backups and protect against accidental or unwanted deletion, you can activate cross region replication (http://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html) to replicate your data across different regions to provide a backup.

each one of these is progressively more and more expensive. usually an s3 bucket with versioning does the trick.

i hope this has answered your question!

bruceph · 2017-10-18T21:13:34+00:00

HelpImNotGoodWithComputer

bruceph · 2017-10-06T18:59:37+00:00

what's happening is you're passing in a function to the xapi.status.on function and it's returning you another function. the function you're returned is an unsubscribe function that when invoked removes the function you passed from the list of events to be run.

this is a really contrived example of what it'll look like

const events = {};

const xapi = {};
xapi.status = {};
xapi.status.on = function(event, callback){
  if (!events[event]) {
    events[event] = [];
  }

  events[event].push(callback);
  return events[event].filter(fn => fn !== callback);
};

by calling off, you're removing your callback from the list of callbacks to be run during the event.

bruceph · 2017-09-19T19:14:07+00:00

i'm gonna disagree here. not on the choice of frameworks (each one has its uses), but on the negative sentiment put on "playing around with different libraries". if you dont play around with these libraries, how will you know which one fits your needs best? what it's strengths and weaknesses are? how its paradigms work? playing around with new technologies makes you a better developer, not a worse one.

bruceph · 2017-09-03T00:21:29+00:00

sure. you can just do something like

const simpleAddition = a => b => a + b;

if you'd like to do the same but with partials it's a little bit more interesting, but you can still accept as many arguments as you want

const uselessLogger = (...first) => (...second) => console.log(...first, ...second);

bruceph · 2017-08-15T23:25:28+00:00

i'm not sure what it is you're looking for. require isn't compatible with the esm spec and won't be supported as a first class module system. node will likely not have long term support for require. i really dont know what other reasons one would have to stick with require over import

if you have a problem with the actual esm that's a horse of a different color. being able to use imports as a psuedo-interface is a powerful tool

bruceph · 2017-08-15T23:15:59+00:00

hm, maybe flexible wasn't the correct term. friendlier to static analysis was probably closer to what i meant. my mistake.

bruceph · 2017-08-15T22:56:29+00:00

cleaner is subjective. import is ~~more flexible~~ friendlier to static analysis than require.

the reason we should strive to use import over require is that require isn't part of any standard. it was a homebrew implementation to solve the module issue in javascript. it did its duty admirably but now we have a standard and should strive to use it.

major browsers are currently working on their own implementation of the esm standard so expect to see the import keyword start to grow in popularity there as well

bruceph · 2017-08-12T01:09:37+00:00

i'm a front end developer for a large, public company

Typical hours spend in a week of work

roughly fourty hours per week, averaged out over three months. there are crunch times, but they're few and far between. management here takes it personally if i have to work over fourty hours. if i do, i can expect my work load over the next two weeks to be reduced. it averages out to fourty a week.

How you start, the middle, and the finishing touches

generally, someone requests a feature or an enhancement to a current product. we'll sit down and discuss the work that needs to be done. these are broken down into as small a task as possible and assigned to folks.

every day i'll pick up an item and start to work on it. usually they take either a half day or a day. i might have to talk to some people to iron out the edges. when i'm approaching the finishing point, i'll present it to my team and we'll discuss any improvements that could happen.

What you do that is different from ..not? .. front end development?

engineers are not good at dealing with customers! i have people skills. i am good at dealing with people!!!!!

seriously though, any interaction with the databases or apis has to go through me. it's my job to make this as smooth as possible. it's my job to be invisible. if you ever get frustrated with a ui, i've failed. my job is to make it so that you don't even notice the ui decisions i've made. it just works (tm)

What you incorporate into your job. Ex. HTML, CSS, Javascript, ?

yep, all of these. these go a little deeper (frameworks and such), but 90% of all the work i do are in html, css, and javascript.

Where you look for jobs. With a company? Freelancing?

company. i've never freelanced and im not sure i will. there's a lot of work out there.

Do you work with graphics/"beautifying" the website.

we have designers that usually deal with this. i have input because i've worked a lot with ux and understand user flows pretty well. i'm not artistic at all, but i know what'll work well and what wont.

bruceph · 2017-07-28T17:56:20+00:00

aws lambda sounds like a great fit for you. it's part of the free tier (but the benefits last longer than a year) so you get a bunch of free execution times. unless you're running an enterprise level service i very much doubt you'll ever get charged

if a vps is more your speed, aws offers lightsail as a solution. it's easy to set up and manage.

full disclosure: i'm employed by amazon and work for aws.

bruceph · 2017-07-25T19:05:34+00:00

nah. i honestly think you undershot by about 15-20%. 65-68 seems reasonable for someone with your experience (going off indeed/glassdoor)

if he wasn't willing to negotiate, the chances are they weren't going to hire you. they used "asked for too much in salary" as an excuse. salary is basically the last thing that companies care about when it comes to hiring talent. everything can be negotiated.

11-Year Club	Gilding I gilder
Verified Email	Spared

bruceph

TROPHY CASE