Location: San Francisco Bay Area
Remote: Open to all (Remote, in-person, hybrid)
Willing to relocate: Yes
Technologies: Ruby, Ruby on Rails, React, React Native, Java, Spring, MySQL, PostgreSQL, HTML/CSS, Javascript, AWS
Résumé/CV: https://drive.google.com/file/d/1iENUTfuqwvsjW6i9LC-eDyx89h_UCYzH/view
Email: ncrandall@gmail.com
LinkedIn: https://www.linkedin.com/in/nicholas-crandall-658849a/
I'm an experienced Software Engineer and Leader with 13+ years of industry experience. Much of my experience includes being an Engineering Manager, but I'm also very hands on, mostly on the backend using Ruby on Rails and Java.
I have a lot of experience integrating and scaling 3rd party APIs into backend systems.
I come with a lot of domain expertise in CRM, specifically integrating with Salesforce. I'm willing to explore new domains as well.
I'm looking for interesting engineering roles or leadership positions. I'm flexible with in person and remote roles.
Location: San Francisco Bay Area
Remote: Open to all (Remote, in-person, hybrid)
Willing to relocate: Yes
Technologies: Ruby, Ruby on Rails, React, React Native, Java, Spring, MySQL, PostgreSQL, HTML/CSS, Javascript, AWS
Résumé/CV: https://drive.google.com/file/d/1iENUTfuqwvsjW6i9LC-eDyx89h_UCYzH/view
Email: ncrandall@gmail.com
LinkedIn: https://www.linkedin.com/in/nicholas-crandall-658849a/
Experienced Software Engineer and Leader with 13+ years of industry experience. Much of my experience includes being an Engineering Manager, but I'm also very hands on, mostly on the backend using Ruby on Rails and Java.
I have a lot of experience integrating and scaling 3rd party APIs into backend systems.
I'm looking for interesting engineering roles or leadership positions. I'm flexible with in person and remote roles.
Location: San Francisco Bay Area
Remote: Open to all (Remote, in-person, hybrid)
Willing to relocate: Yes
Technologies: Ruby, Ruby on Rails, React, React Native, Java, Spring, MySQL, PostgreSQL, HTML/CSS, Javascript, AWS
Résumé/CV: https://drive.google.com/file/d/1iENUTfuqwvsjW6i9LC-eDyx89h_UCYzH/view
Email: ncrandall@gmail.com
LinkedIn: https://www.linkedin.com/in/nicholas-crandall-658849a/
Experienced Software Engineer and Leader with 13+ years of industry experience. Much of my experience includes being an Engineering Manager, but I'm also very hands on, mostly on the backend using Ruby on Rails and Java.
I'm looking for engineering or leadership positions. I'm flexible with in person and remote roles.
Experienced Software Engineer and Leader with 13+ years of industry experience. Much of my experience includes being Engineering Manager, but I'm also very hands on.
In my current role I've built integrations with Salesforce Marketing Cloud and Adobe Journey Optimizer with Java and Spring. I'm also very experienced with the Ruby on Rails framework. I'm open to full-time and contract positions.
This was one of my biggest issues, even as an experienced developer with a CS degree. I always felt a step behind since I wasn't fluent in the latest and greatest framework. All of that changed when I mentally decided to focus on one language, namely Ruby. It's amazing how much you can do with any one language even though it's not fully optimized for a specific use case you need.
I can honestly say this was the biggest pain for me as a contractor. I decided to go without health insurance and paid the fine for not paying quarterly taxes just because I didn't want to deal with the hassle.
Even though this is a free tool, I would have gladly paid for it to help alleviate those issues.
Noted! We're definitely excited to help solve this pain point. Nice to know that users would be willing to pay for it - I think that makes the "free" even more compelling.
So after going back and forth with our startup on SOA or not, I have felt like separating these services out of (in our case) a monolithic Rails application has made sense. I would like to use Sinatra for one service, rails for the web interface, and possibly Python for the last service. I understand this adds a lot of overhead by creating an interface and authentication for each service.
For me the logical division of services seems to make sense especially when using 'the right tool for the right job'
I may be over optimizing, but I think it will pay off at a later date with more developers and the need to scale each service separately. Maybe someone can point out issues with this thinking (besides those addressed in the blog post).
To me the crux of the issue is the interface. If you can define a very clean interface without having to do a lot of contortions to get the data you want where you need it, then extracting a service can be relatively low overhead. But what often happens is at the 30,000-foot view it looks like a service makes sense, but then when you get into the details you realize the separation can not be as clean as you first envisioned.
I'd disagree with this. In my experience everytime it has seemed like the interface was too complex too support services correctly, it's been because the break for the services was at the wrong level of abstraction. SOA tends to work best when you define discreet chunks of functionality and each service is only responsible for that chunk. Just like developing testable code, you want to make those chunks as small as possible, without losing your mind at the shear number of services. For example having an order service and shipping service as opposed to a just an order service that handles everything is more likely to make sense IMO.
Your argument doesn't seem to address my point. You're saying if the interface isn't good you're at the wrong level of abstraction. Okay. How does that contradict the idea that the interface is everything for creating a successful SOA?
I'm saying that it's rare that SOA isn't a proper fit for a web application and if it seems like a poor fit you likely haven't abstracted your interfaces to the right level. Your monolithic app is going to suffer from poor design just as much as an SOA based one. Your point seemed to be that certain applications could be well designed and still not a proper fit for a SOA. I think if an app is well designed it will by default be a proper fit for SOA. If you were not implying that I apologize. I guess my position is that nearly any complex web application would benefit from SOA.
My point was really nothing to do with whether an application is a fit for SOA. It's more about how to design an SOA. Your point about a poorly designed SOA being an equally poorly designed app is well taken, but I think it's more work to design a good SOA than a good monolithic app. And this is where the effort of designing the interface comes in.
In a monolithic app interfaces can be more fluid because you can have automated tests and static analysis and compile time checks verifying that a given change works. That means you can prototype and iterate faster while the business requirements may still be churning considerably. To realize the benefits of an SOA you need a much more stable interface and some way to handle validation and correctness of the wire protocol. If you do it right and come up with a stable interface, you gain the benefits of decoupling system administration, scalability, and even development to a great extent. But if you do it wrong you end up a lot more work for an equivalent business logic architecture, and if you don't have any scaling issues than the cost-benefit is likely not to be there.
My rule of thumb about whether an SOA is a good idea to pursue at a given point in time is much more related to the team size than the nature of the app.
If you use a message queue system like RabbitMQ, and simply publish messages as JSON you have interfaces, authentication etc. done already. We have 17 different services internally, in four different languages, all communicating over AMQP with JSON messages.
(Disclosure: I'm owner of CloudAMQP - RabbitMQ as a Service, www.cloudamqp.com)
Yep it doesn't. So actually, on chrome, without an autoscroll extension, there is no way to scroll that page (apart from the with the right cursor button, which is way to slow to actually be valid) on a normal desktop pc. Happy new world.
I'm a Rails developer with several years of experience and a CS degree. My area of expertise is building APIs and integrating with external services. I will build out your MVP quickly or help engineer an existing product. Lets talk in person, hangout, or skype.
Skills
Ruby on Rails
3rd party APIs (Twilio, Facebook, Google, etc.)
HTML / CSS / Javascript
The usual advice applies, if you are really worried consult a lawyer. Many will do 30min - 1hr consultations for free and will enlighten you to the risks about your app specifically.
An LLC will protect you from most liabilities and is probably the easiest way to protect yourself in this case. Worst case scenario they sue the company and get all $0 worth of assets from it (assuming no sales).
Applying for an LLC is fairly simple and straight forward. Most states allow you to create one online for less than $100. It honestly takes less than an hour to set them up. Beware the tax implications of doing so, it's a pass-through entity meaning profits and losses are passed directly to your personal income. This is usually not a big deal and most tax software makes this very simple to document at tax time, just keep a record of all profits and expenses.
This is just from experience so take it with a grain of salt. Hopefully this gets you started with some further research.
> Worst case scenario they sue the company and get all $0 worth of assets from it (assuming no sales).
But worst case has to assume significant sales, or what's the point of the whole discussion? And are you suggesting the OP doesn't defend in court? Because if not, then legal fees will kill OP. If he doesn't defend, then I guess it is cross your fingers and hope the jury in East Texas holds an Opposite Day that day.
I come with a lot of domain expertise in CRM, specifically integrating with Salesforce. I'm willing to explore new domains as well.
I'm looking for interesting engineering roles or leadership positions. I'm flexible with in person and remote roles.