Sailthru | Senior Software Engineers w/ full-stack experience | New York City (NYC) | Full-time, Onsite
Sailthru is a technology company focused on optimizing marketing messaging across all channels. We hate spam and strive to help marketers deliver the right message to the right customer at the right time. Our customers are among the largest organizations worldwide, and they use our platform to provide a connected customer experience across email, web and mobile.
We're looking for an experienced product engineer with a deep interest in all points of the product lifecycle to help architect, build, and maintain several of our key products. As part of a cross-functional team, you'll partner with designers to make a powerful product simple to use and an experience our clients love. We're currently making a big push to scale our product and tech stack. A few things we're doing: building modern component-based UIs (React, Redux, CSS Modules, Styled Components, Storybook), leveraging ML for intelligent features, and investing in our next-gen computing infrastructure and data pipelines (Kubernetes/Event Streaming).
Sailthru | Senior UI Engineer w/ full-stack experience highly preferred | New York City (NYC) | Full-time, Onsite
Sailthru is a technology company focused on optimizing marketing messaging across all channels. We hate spam and strive to help marketers deliver the right message to the right customer at the right time. Our customers are among the largest organizations worldwide, and they use our platform to provide a connected customer experience across email, web and mobile.
We're looking for an experienced product engineer with a deep interest in all points of the product lifecycle to help architect, build, and maintain several of our key products. As part of a cross-functional team, you'll partner with designers to make a powerful product simple to use and an experience our clients love. We're currently making a big push to scale our product and tech stack. A few things we're doing: building modern component-based UIs (React, Redux, CSS Modules, Styled Components, Storybook), leveraging ML for intelligent features, and investing in our next-gen computing infrastructure and data pipelines (Kubernetes/Event Streaming).
I always felt that Interface Builder is _for_ designers who want to visualize and use something (only somewhat) closer to photoshop. A developer might more likely come at it from the other direction, not even touching IB and doing it all in code, then maybe adding modular IB elements when the layouts start to make the code unmanageable.
If you're not using interface builder as a developer, you're wasting a huge amount of time. Doing advanced screens (mostly) through code makes sense, but often it's a lot faster to use IB for putting together / building the more basic parts of an app.
I totally agree. I wanted to expand a little on basic vs advanced screens, and suitability for IB.
At work we had two teams who had very different opinions of IB's usefulness. In our case, it was based on the nature of each application. IB does not provide much value when the majority of the screen is dynamically determined: different elements based on user preferences, locale, document contents, etc. The team that disliked IB, their app was almost all dynamic (and lists/tables, whose cells were also fairly dynamic).
Our team, on the other hand, had a very static UI. It had very little runtime customization (other than the contents of labels, images, etc). We loved IB.
And then child ViewControllers came along, and made it easier to mix static/dynamic content on the same screen.
I haven't used UIStackView yet, but I suspect it also will help with screens that contain dynamic content.
This is a good point. I've been dealing almost exclusively with highly dynamic UIs, and that's almost certainly skewed my perception of IB's usefulness.
We built our designs on a modular approach where each element is contained in a tableview cell, so that part is done by code. The cells themselves make use of Auto Layout though.
While I absolutely hated AL at first (and the IB just plain sucks) I do find it very time-saving once it clicked.
For small to medium changes, by reading the XML. Everything is named sanely, and the XML hierarchy matches the view hierarchy. Constraints can be a little hard to understand, because they use opaque identifiers, but it's possible. I'll occasionally have to open the storyboard/NIB in Interface Builder to confirm/disprove something.
For large changes, it can be unmanageable. But large changes are hard to code review anyway, so we try to avoid those.
Interesting. I've worked with a few designers who had Xcode _installed_, but they were mostly using it for the Simulator. Using IB wasn't something they were comfortable with. I'd be really impressed with somebody who's a Sketch/Photoshop wiz coming over to IB and being productive.
On the flip side why would a non-developer bother to install Xcode and learn IB when they can export their ideas directly from Sketch/Photoshop into clickable "prototypes"?
Back when IB was a separate tool, I'd agree with you. I'm not going to look for old docs, but I'm pretty sure I ran across something from six or seven years ago that mostly said, "IB can be used by non-programmers to make a UI, and then dev can create the code to hook to the IBActions.", or something like that.
Whether it was written down or not, it seems like a good idea in theory. The old, stand-alone IB wasn't all that hard to figure out (though struts and springs might bring the death of your sanity). Get the UI all prettied up, and hook up an implementation behind it. Not that I've ever seen that in practice, however.
Ember FastBoot is a cool project. Glad to see they are close to production ready.
Tom mentions they are leveraging App Cache, which is notoriously hard to work with and will likely be deprecated. That's the scrappy stuff they are doing, comparing it to how jQuery once made the DOM easier to work with.
If a future Ember release was able to abstract the client-side caching between App Cache and ServiceWorker and automatically "upgrade" my apps to use ServiceWorker when available, that's a big win. I'm not sure that's possible though...
Seems like many of the features of the full Facebook are there. I wonder if they are leveraging their React components to render the same stuff on the server...
I'm not quite sure this is necessarily the case - I noticed that on the regular FB site, it has one notification for two friends having a birthday, and yet in this basic version, it claims I have two notifications for the same notification.
Wondering the same. What if this was Github? What if private repos were somehow exposed? All these team apps could expose sensitive data if targeted/breached.
Does your company use google apps for email? If not, can you understand why some companies do? Same thing IMO. It's a calculated risk that is OK for some but not for others.
If I was managing the IT dept for a government security contractor I wouldn't be using cloud email.
If I'm knocking up the next cloud service mashup, I'm fairly sure I'd be storing the code in a private github repo until there was a need or decision to change.
So yes, sensitive code is stored in public cloud sites. Sensitive emails are too.
You don't have to rely on Github, you can use Github Enterprise which gives you a little bit more control and allows you to run it on your own servers.
That said, my understanding is that authentication even for Github Enterprise is done through Github itself. (Someone please correct me if I'm wrong)
I've seen passwords and other sensitive config data committed to public repos in GitHub. I wouldn't even be slightly surprised by people keeping sensitive IP or trade secrets there, on the assumption that if it's a private repo, it must be safe.
To clarify for others who might not see this: Where do you think sensitive data - private keys, passwords, etc. - should be kept? For instance, when setting up infrastructure for a company, how would you desire that data be shared across users?
Once might have the same reservations about something like Heroku - or really any cloud provider - given that at some point, you are pushing code to a server that is owned by another company whose security you cannot audit.
If you use ansible, there is a great feature called ansible-vault that allows you to store all those sensitive bits right in the repo but encrypted and automatically readable by ansible when needed.
Sailthru is a technology company focused on optimizing marketing messaging across all channels. We hate spam and strive to help marketers deliver the right message to the right customer at the right time. Our customers are among the largest organizations worldwide, and they use our platform to provide a connected customer experience across email, web and mobile.
We're looking for an experienced product engineer with a deep interest in all points of the product lifecycle to help architect, build, and maintain several of our key products. As part of a cross-functional team, you'll partner with designers to make a powerful product simple to use and an experience our clients love. We're currently making a big push to scale our product and tech stack. A few things we're doing: building modern component-based UIs (React, Redux, CSS Modules, Styled Components, Storybook), leveraging ML for intelligent features, and investing in our next-gen computing infrastructure and data pipelines (Kubernetes/Event Streaming).
Senior UI Engineer: https://boards.greenhouse.io/sailthru/jobs/1332779
Senior Software Engineer: https://boards.greenhouse.io/sailthru/jobs/1420238
Senior Product Manager: https://boards.greenhouse.io/sailthru/jobs/1404874
Director of UX: https://boards.greenhouse.io/sailthru/jobs/1412204
+ more: https://www.sailthru.com/careers/list/
Unlimited time off | Catered lunches | Health, Vision and Life Insurance | 401K & more