heme

Hy-Vee - https://hy-vee.com | West Des Moines, IA | Full-Stack Software Engineer | QA Automation Engineer | Full Time | ONSITE or REMOTE (US ONLY) | JavaScript, TypeScript, React/React Native, Next.js, Kubernetes, Google Cloud

We are a large retail grocer with 265+ stores in 8 states in the Midwest. We've been in the ecommerce grocery business for 5+ years and successfully compete with the national players in this space. We are focused on making our customer's lives easier, healthier, and happier through our digital products.

Our teams help build the digital products that our customer's use to order groceries for pickup/delivery, refill prescriptions, earn & redeem in loyalty, and order prepared food online.

Our software engineers work in modern stacks including GitHub, TDD, CI/CD, part-time paring, & automated testing. We ship features to a very large, active, and loyal user base on a regular cadence.

We are proud of our teams, our culture, and the products we build & support. If you are an experienced software engineer, are capable of working collaboratively on a product team, and have a passion for software then we'd love to talk with you.

More Info about us: https://innovate.hy-vee.com/

Position Descriptions & Apply Online or send your resume to Amanda at AWittmaack@hy-vee.com

Software Engineer – Web and Mobile: https://www.linkedin.com/jobs/view/1606763127/

Software Engineer – Data Integration: https://www.linkedin.com/jobs/view/1803921752/

QA Engineer – Digital Customer Experience: https://www.linkedin.com/jobs/view/1870983782/

Hy-Vee - https://hy-vee.com | West Des Moines, IA | Full-Stack Software Engineer | QA Automation Engineer | Full Time | ONSITE or REMOTE (US ONLY) | JavaScript, TypeScript, React/React Native, Next.js, Kubernetes, Google Cloud

We are a large retail grocer with 265+ stores in 8 states in the Midwest. We've been in the ecommerce grocery business for 5+ years and successfully compete with the national players in this space. We are focused on making our customer's lives easier, healthier, and happier through our digital products.

Our teams help build the digital products that our customer's use to order groceries for pickup/delivery, refill prescriptions, earn & redeem in loyalty, and order prepared food online.

Our software engineers work in modern stacks including GitHub, TDD, CI/CD, part-time paring, & automated testing. We ship features to a very large, active, and loyal user base on a regular cadence.

We are proud of our teams, our culture, and the products we build & support. If you are an experienced software engineer, are capable of working collaboratively on a product team, and have a passion for software then we'd love to talk with you.

More Info about us: https://innovate.hy-vee.com/

Position Descriptions & Apply Online or send your resume to Amanda at AWittmaack@hy-vee.com

Software Engineer: https://www.linkedin.com/jobs/view/1606763127/

QA Engineer: https://www.linkedin.com/jobs/view/1770603845/

... step back and embraced an approach that aligned well with our product requirements and needs of the team.

This ^^^. Everyone has an opinion on the Internet... frontend, backend, no-end. It's probably not going to align perfectly with your needs (are you Google/Facebook?) . There are a lot of tools & specs out there. If your blindly following someone else's opinion without truly understanding your users, product, & team you'll probably accrue debt.

Also, devs often forget the team. If your choice of tech cuts the team's velocity in half then it probably wasn't a good choice... even if it had some other technical benefits.

"Please Stop Using Local Storage" is not helpful and will confuse people who are unfamiliar with browser storage. I'm guessing the author meant, "Please Stop Storing Application Data in the Browser Instead of a Server-Side Persistence Layer (DB)". Local Storage is a specific thing in the browser and is useful in specific cases.

I found a good comparison of all browser storage options on Quora: https://www.quora.com/What-is-the-difference-between-session...

I believe all of the author's stated shortcomings of local storage apply to all browser storage options.

* String Only

* Synchronous

* No Web Worker Support

* Size Limits (smaller for cookies but all have limits)

* Any JavaScript code on the page has access (don't include scripts you don't trust)

Also, keep in mind...

* There is no guarantee the browser will encrypt the content on disk. I believe chrome encrypts cookies, but I'm don't think others do. I don't believe local storage is encrypted at all. Session storage & session cookies should only be in memory. You shouldn't be storing PII in the browser anyway.

* These storage options can't be accessed by other domains as they conform to the same origin policy, but this is an important caveat: The "origin" of the script is the page it is executed in, not where it comes from. So, if you include <script src="http://somehacker.com/superLib.js"></script> it will execute in your origin and can access everything. Protect your users by only including scripts you know are safe. * https://stackoverflow.com/questions/12543978/same-origin-pol... * https://developer.mozilla.org/en-US/docs/Web/Security/Same-o...

In short, do some research and use the right tool for the right job.

Care to share? I have yet to find the right mix of aliases that replicate SourceTree's overview of the whole project.

In my experience as a software developer... Technical diligence, and technical debt, only matter in the way they affect revenue & growth. Technical people are usually more acutely aware of how they will be crushed by the current debt they are accumulating. Business is more acutely aware of how the business will fail when growth goals are not met. Both things should be everyone's concern. Striking that balance, and communicating serious pitfalls and shared goals should help give perspective.

Can you elaborate on the scaling problems you were having?

Anyone know if....

A. It is possible to request your "advertising profile" from them.

B. Can a customer request that gathered information on them be destroyed?

C. If you opted-out today (like me) does that mean that they stop collecting information and continue to sell "your devices" ad profile? Or do they also stop selling your info?

(sending these to Verizon. I'll post if I get answers)

Not doubting you, but I would love to see the methods to make this happen. Is your concern from a 3rd party script included on the page?

From my experience memory is safe between origins in the same way cookies are. And it is the dev's responsibility to not do something stupid with the token like window.FacebookToken = OAuthToken;. But that holds for traditional session cookies as well.

Usually the token kept in memory is one distributed by the application and is not that which the services send back.

What is application in that sentence? The API?

Isn't that what this lib does?

A client-side Javascript SDK for authenticating with OAuth2 web services and querying their REST API's.

- I assume the API issues the token - This lib receives it and uses it for subsequent calls - The token is destroyed when browser session is closed.

Isn't the point of this not to secure some thing, as in "no access", but to sign something and trust it (i.e. a server signs a token and hands it off to another machine/app)?

If your point is "nothing is secure in the browser" then that includes the secured content sent down by a secure server no matter the method.

Is not a session cookie the same thing? I'd argue if your tokens only live in memory they can be more secure. It also depends how long your tokens live or how many requests they are good for. No?

Are you writing tests for these views? Any lessons learned?

I currently have Grunt + the RequireJS Optimizer building ~5 js files from 20+ AMD modules. So, with harp I would move that build script away from my app and into Harp? Sounds very interesting, but does this separate the application from the build script?

Less/Sass seems easy, but I'd like to see more regarding JS build/min/concatenation scripts in Harp. Or is this not its goal?

Mosquitoes help pollinate blueberries. Without blueberries we have nothing to anti the oxidants.

I keep seeing "pure html templates" in many comments about AngularJS, but they don't seem to be completely "pure" from my perspective. Couple of questions for you...

1. AngularJS directives do not seem to conform to valid HTML. Does this matter to Google from a search perspective? I realize that single-page applications quite often have other SEO problems, but valid non DSL HTML templates seem like they would be of value for all the reasons you outline above.

2. I quite often see the following type of examples in an AngularJS tutorials. How is this different from Handlebars or Mustache? This still ties my template directly to AngularJS, no? Also, this is usually not understood by designers tools.

    <pane title="Localization">
        Date: {{ '2012-04-01' | date:'fullDate' }} <br>
        Currency: {{ 123456 | currency }} <br>
        Number: {{ 98765.4321 | number }} <br>
    </pane>

- Facebook wants to know where I live so it can show me more advertising.

- Google also wants to know where I live so it can show me more advertising. However, Google also uses that information to provide useful tools such as directions, search, etc.

- I am much more likely to give Google my info because they give me all of these extra useful tools. Facebook provides nothing except a place for my mom to see photos of her grand kids. AS soon as she is on G+ I will be dropping FB.

Thanks for the post. I'm at the beginning stages of planning a large single-page web application. I'm very interested in a Google-backed framework, but I continue to have concerns when reviewing tutorials like these. I'm genuinely interested in hearing thoughts on the points below.

Here are some of my concerns...

1. Spaghetti Code. "... AngularJS let you execute expressions directly within your HTML pages." Why do I want JavaScript code in my HTML at all? I normally like absolutely clean HTML templates for two main reasons: 1) They can be used & rendered anywhere 2) they are easier to maintain.

2. AngularJS Directives seem to mix control structures & Code inside HTML templates. This seems difficult to maintain... <div data-ng-repeat="user in users"> ... </div> JavaScript can do loops and most developers understand that. data-ng-repeat is only understood by AngularJS, which means this template will always need to be rendered by AnglularJS. Also, is the template forever tied to a "users" collection? What if I would like to reuse the template for "clients"?

    <div data-ng-repeat="user in users" data-ng-show"=user.gender == 'female'">
    ...
    </div>

3. It seems as though the debate of DOM based rendering vs string based rendering is still going on, but do I have a choice with AngularJS? Right now, I'm not a fan string based rendering on the front-end because it locks me into a specific rendering engine (e.g. Handlebars, Mustache, Underscore etc.). Also, if you have no {{tokens}} in your templates you can render them on the server and then later update them on the front-end (I see the AngularJS devs say this is bad, but hybrid can be useful for security, SEO) . There are a number of DOM based templating engines out there. One I like very much is transparency. They have a great FAQ on this topic:

https://github.com/leonidas/transparency/wiki/Frequently-Ask...

4. "Using proper separation of concerns, controllers should never contain anything related to the DOM." Why is this the case? When would you ever use your controller outside of controlling the DOM in a Template? Is AngularJS's view that the Controller contains the event-handling function, but the View/Template does the binding?

We need to implement something along these lines to secure our API. This is interesting, but I need help understanding why the server can't just provide a random session_key after successful authentication? As long as that session_key is valid on the API then do I care about GUIDs and Public Keys? What is the "Needham-Schroeder-Lowe Public-Key Protocol" portion of this providing?

WSDL for REST is happening, but see the JSON schema discussion below.

    WADL is a machine-readable XML description of HTTP-based web applications (typically REST web services).

Aren't you worried that there is too much "protocol" information in your returned object? I'm struggling with this now. I've come to think the API should return exactly what was requested. So instead of a very specific structured object...

    "collectionName": {
      "total": 861,
      "limit": 10,
      "offset": 100,
      "pages": 87,
      "links": [
        {"rel": "first", "href": "/api/things?limit=10"},
        {"rel": "prev", "href": "/api/things?limit=10&offset=90"},
        {"rel": "self", "href": "/api/things?limit=10&offset=100"},
        {"rel": "next", "href": "/api/things?limit=10&offset=110"},
        {"rel": "last", "href": "/api/things?limit=10&offset=860"},
      ],
      "items": [
        ...
      ]
    }

    [{},{}]

Any thoughts are welcome and greatly appreciated!

EDIT: Adding to this comment because pfraze's comment below (https://news.ycombinator.com/item?id=5471523).

It seems as though the Link Header item could be the appropriate place for this: http://www.w3.org/wiki/LinkHeader

Where does the meta information about the resource belong? In the object/resource returned OR as meta information in the header (with other HTTP information). Is this a needless hindress for

Isn't this a bad idea outside of formatting a number as currency?

Also, Why not let JavaScript inject your model data directly into plain vanilla HTML templates? In other words, don't use any template tags at all. These 2 projects are really piquing my interest.

http://blog.nodejitsu.com/micro-templates-are-dead

https://github.com/leonidas/transparency/wiki/Frequently-Ask...

Side benefit is that you can still pre/hybrid render from the server in whatever language you like.

Doing research for my first Single Page Application project. Angular seems extremely popular, but something continues to confuse me.

Can someone explain why this:

  <input ui-event="{ blur : 'blurCallback()' }">

  <input onblur="blurCallback();" />

This is a very cool idea. Is there any intention to tie this to your commits?