botskonet
https://www.indeed.com/cmp/Emprise-Corporation/jobs/Web-Appl...
https://www.indeed.com/cmp/Emprise-Corporation/jobs/Senior-S...
We're looking for Javascript developers, though HTML/CSS experience is important too.
We use Angular, lodash, bootstrap, and a ton of smaller libs. We're soon going to support ES6 too.
A group of people trying our best to build an awesome and ever-improving application and we're looking for talented, passionate developers.
Can anyone recommend a more general resource? Possibly something that covers a wider range of topics like intranets, VPNs, self-hosted servers, etc? I know someone who thinks he's all that but seriously needs to read more of this stuff.
He values private networks over SSL (as in public websites don't even have SSL), salts salts and decrypts stuff by looping through timestamps within a range close to the transmission, and more.
I've known about Kubernetes for some time, but my current job never deploys anything that Kubernetes could improve, so I put it aside and hoped to someday get a chance to toy with it.
I've setup vagrant images pre-loaded with our app for several non-developers to use locally but it sounds like Kubernetes would be a far better way to manage those as well as staging servers.
Unfortunately my current company is 100% against third-party hosting/involvement so I couldn't even use it for staging - our stagings servers are Windows-based, ancient, and internal...
Emprise is an established nautical software and hardware company based in Ledyard, CT.
We're looking for several front-end developers with solid javascript/es6+ experience. Our application uses AngularJS (v1), lodash, html5, and scss. You'll also do a small amount of Java for server API endpoints/controllers.
https://jobs.github.com/positions/b4de5f62-0520-11e8-8853-f9...
What would be the best way to learn, for someone looking to invest $500+, who's never done much investing before?
Outside of ~10 shares of Starbucks stock given to me when I worked there in 2001, this has been my only experience.
P.S. Those Starbucks shared have been long-lost - somehow they moved them from Schwab to another company and no one told me where/how). I forgot about them until today.
EDIT: Looking at my docs, I bought 7 shares at $18.275 in April 2001. The stock price is $60.55 today. I need to figure out who holds these and see what I can do to reclaim them.
EDIT2: I found them. I found where the original account was, called them and got the details. Sadly, the account was marked as dormant and I learned about "Escheatment". The stocks were cashed and the amount is now held by my state and I have go through several hoops to reclaim.
I want to see an understanding of git - they have repos with appropriate commits, good commit messages, awareness of licensing, decent READMEs or info for collaborators
I want to feel like they understand how open source works - they've filed or participated in issues/discussions, they've starred/forked repos, they've opened PRs, they've managed issues/PRs on their own repos.
I want to see how they manage their projects/repos. Do they use a package manager? Do they have linting or build tools? Do they use CI? Have they kept the repo clean and ready for others? Do they use automated testing?
I don't expect to see all of this - but if someone has none of it, it's clear they have a lot to learn and aren't ready for the job.
Every single aspect of space travel is an engineering/mathematic/scientific marvel. Not only did we plan, build, launch these, (before I was born) but we're still communicating (until we can't).
I'm reading links people have posted here, trying to understand how we communicate with these probes. It's fascinating.
Projects like ui-grid are dying and ui-bootstrap is dead and they're moving to Angular support only. We're suddenly using tech that's being abandoned a lot sooner than we foresaw.
I have my issues with Angular v2+, though overall it's way better than v1, but I truly hope the same doesn't happen to those making an investment in this new platform.
Add to that the frequent execution and performance issues with watches and we deeply regret having to deal with it now.
Add to that having to learn the painful guts around digest-related executions. Watches fire on init so you have to ignore those first calls. Tests are nasty because timeouts have to be flushed manually, and $q promises won't resolve until you call $apply, etc. It quickly became "WTF is going wrong internally".
Angular 2 is a lot better, but at this stage I think so many former AngularJS/v1 developers went the react/vue route and don't see any reason to return.
I agree with communication - it's the only day-to-day contact you have with co-workers and if you aren't a good communicator, it's not going to work.
If your entire team works remotely then it takes more planning, and it may require some sacrifices regarding your schedule. However, if part of your team works in an office then remote workers likely need to be available during similar hours.
I agree with learning to ignore "work" when you're off-hours and ignoring "home" when you're working, and how this is done depends on the individual. Traveling to a local coffee shop or wifi hotspot defeats the purpose for me. I don't want to trade one noisy place with people for another, at least regularly.
One big issue he doesn't mention is how other people you live with handle your work. They need to understand that whenever you're working, you need to be working. Not helping with laundry or chores, not babysitting, etc. It's a difficult thing to teach, but it's critical. For those married with kids it's a big problem, but for those single it's not.
I disagree that it effects motivation. There are always temptations at home but if you enjoy doing the work it shouldn't be a battle of will power.
Building the DOM via JS wasn't going to work for us. We had to re-learn how make simple things and we were at the mercy of the Ext API. The resulting DOM was incredibly bloated, different in IE, and was a nightmare to style.
Template-driven apps like Angular, JSX in React, Vue, etc are much easier to use overall. Less to learn, faster adoption for new developers, cleaner separation, better portability, and small, clean, and consistent output.
To be fair, the original authors of our application had little idea what they were doing either and misused/abused Ext, which made everything 100x worse.
However, there have been times where being forced to define a schema has been painful. If our app has to store dynamic keys/values it all winds up as records in a relational db table acting like key/value store. Whereas in Mongo we can just store the document, without affecting the entire table schema.
I want the best of both worlds...
I work with people who did things their own way for 10+ years, never worked as team, never kept up with a quickly changing industry, never improved their skills, that now they're opinionated, they feel that as long as something works it's good to go, etc.
Introducing them to a code review workflow exposed how truly uneducated they were. Code review turned into education sessions, explaining how fundamentally they've misunderstood or misused CSS, javascript, or the tools we use.
It's dramatic how much money and time is wasted because no one with authority to fire them wants to. Back when I ran my own studio I let people go the instant it became clear they weren't going to make it, but these people couldn't pass a simple interview with me.
My company sees it but keeps trying to find ways to solve the problem. You can't throw training at it, you can't throw more meetings.
Typescript is an amazing tool and will be better once there's even wider support. Observables are interesting and RX.js has been useful to me. Zones are interesting but I've not had a real chance to use them.
But, I think putting these and many more concepts together make Angular even less accessible to a majority of developers. Developers can choose these components individually and mix and match for the project, but Angular has made all of these decisions already. That works for some people, but not enough.
Add to it the extreme confusion over naming and the massive paradigm shift from AngularJS 1.
I agree that Vue, React, and other libraries do a much better job and aren't complete packages, you can put together the foundation you need.
The two-way binding/digest nature has really become our enemy. Everything we write has to account for digests and we've wound up with some terribly ugly code to account for digest problems.
Angular 1 is great for hobbyists and it makes implementing simple forms easy but when you use it for an enterprise app, it hurts.
Our app is still vastly better than decade-old 1.0 we've replaced, but we sure hate the digest now.
As a developer I would LOVE to have everyone submit a failing test or a PR rather than reporting issues but that's just not feasible. Most never will, because there's a learning curve they don't have time for - the language, the tooling, the product itself, Git/github/PRs, etc.
As the project maintainer, that's what I signed up for. It really sucks sometimes, but I'd rather sort through the junk and personally fix the issues people report than funnel everyone through hoops they likely won't spend time on and lose that valuable feedback entirely.
As a developer working on a Steam game, I've decided not to let myself down this path. Kickstarter is tempting, but I'd rather release something when it's ready and build from there - if someone pays me, I want it to be for a product they can have now.
I would also add that for any web app truly utilizing these libraries, you're going to have to know how they get compiled and where your data is coming from. With Angular you have to learn about scopes, digesting, linking/compiling, etc.
Two-way binding was amazing to me when I first took up Angular, it made common tasks so easy but on an enterprise-level application it's a nightmare because you're quickly dealing with digest/event cycle issues, especially during automated testing. The control over data flow that React prefers makes the easy, common tasks more time consuming, but overall saves a massive amount of complexity.