ahochhaus

SameGoal Inc | Staff Software Engineer | Madison, WI | ONSITE (Post-Covid) | Full-Time | https://samegoal.com/

SameGoal's web application allows districts to collaboratively and compliantly document student participation in K-12 Special Programs such as Special Education, Gifted Education, English Language Learning and TGRG. We are a privately held, profitable company that operates without external capital to ensure stability and strategic direction.

We are looking for someone with 5+ years of Software Engineering experience ; 10+ preferred, who can architect and develop significant infrastructure projects, debug complex systems to isolate and resolve problems quickly, mentor junior engineers to increase their productivity and foster a highly collaborative environment, develop key new features & functionality end-to-end including modification to our frontend and backend, initiates and leads tactical engineering projects to streamline operations across the company, and can keep our users happy with a user-friendly, low latency, highly stable application experience.

Technology Stack: Backend - Go, PostgreSQL, K8s | Frontend - Closure Tools, SPA | SCM - Git, Gerrit

Competitive salary and benefits package included. FLSA: Exempt. To comply with federal law, SameGoal participates in E-Verify. SameGoal is an Equal Opportunity Employer.

To apply, email cover letter and resume to jobs@samegoal.com

Thanks for the clarification. I did not realize that `upgrade-insecure-requests` applies cross origin. If you do not load any insecure content is setting HSTS and `block-all-mixed-content` the best strategy?

Does using `Content-Security-Policy: upgrade-insecure-requests` in addition to HSTS add value?

MS open sourced ChakraCore (the core of the Chakra JavaScript engine). EdgeHTML is still closed to the best of my knowledge.

Google's standard template language (soy / closure-templates) does mininfy whitespace by default [1]. However, it does not omit optional tags. I think this is why the style guide is written as it is.

Still, I agree that both types of optimization / minification should be done by the tooling layer.

[1] https://developers.google.com/closure/templates/docs/concept...

I agree that the API limitation is most likely not malicious and I did not intend to imply otherwise. Still, lack of malice does not change the fact that the Google Cast extension has a competitive advantage over other non-Google extensions (which can't use all of the same APIs).

One example of "google only APIs" that I ran into recently is the chrome extension browserAction.openPopup API. This API is whitelisted (in stable) for use by the Google Cast extension. Extensions authored outside of Google cannot use it. This is creates an uneven playing field.

https://bugs.chromium.org/p/chromium/issues/detail?id=436489

Fair point. It is reasonable to demote this post.

Personally, I always read the release notes but am less interested in the press release. I think many others prefer the opposite, hence my posting both. You raise a valid point though.

This post links to the release notes. The post you mention links to the press release. They contain similar but different information.

Interesting. Can you offer any details on which production Google apps were presented?

For a bit more context, the technology that allows the client to communicate to the server which hostname it is attempting to connect to is called Server Name Indication.

https://en.wikipedia.org/wiki/Server_Name_Indication

Great feedback. We are too light on details. I'm adding a more detailed description shortly.

The original idea with the video was to show the types of functionality that FormBig exposes (eg: integrated logins, JS-based logic, rich text editing, etc) rather than the details of how one achieves them. However, I think since we went that path it is important to get more details in the body of the page.

Thanks for the pointer to MS Lightswitch I'm learning more about it now.

We don't have a final pricing model figured out yet, but we would like to support applications with a variety of needs. If we had a per-form based pricing option would that meet your needs?

Can you describe your use case a bit and the other platforms you have looked at thus far?

The two co-founders (myself and eksurfus) are here to answer any questions. We are hoping to gain insight into specific use cases for FormBig to guide our to market strategy and development priorities. Thanks for any feedback you can offer.

I agree. If at some point dropinchat.com allowed for messaging between networks XMPP support would be great to add. At this point we only allowing for messaging other drop in chat users so no such protocol is needed. My only point was that we didn't "reinvent the wheel" by not using XMPP. Instead we just don't allow cross network messaging yet.

Sorry for the XSS problems. They are fixed now so it is safe to visit and test again if you like. Thanks owenversteeg for warning everyone.

At this point dropinchat.com does not support sending messages to more than one user. However, we do plan to add that feature as our team has time.

The documentation on dropinchat.com mentions "groups" as a set of users which are allowed to see one another and message back and forth. Our team thinks this use case might be helpful, for example, for a website administrator to limiting communication between members on a given organizational team or individuals in a certain building, etc.

Hi scrollaway. Thanks for the support.

XMPP seems really great in a context of needing to inter-operate with other servers. However, for our use-case all communication was in a silo of a single site so this was not a major benefit to Drop-In Chat.

Our team wants broad broad browser support (for legacy corporate deployments) and a well-tested client side module. BrowserChannel, which is used for gmail chat, is very widely deployed and well tested.

Maybe I'm missing something, but even if we went with XMPP, wouldn't Drop-In Chat still need a way to stream messages from the server to the client? If so, we would still need to rely on a transport mechanism like websockets/XHR streaming/forever iframes for the in-browser real time message delivery. BrowserChannel/WebChannel bundles up this abstraction nicely and hides all the ugliness of dealing with browser quirks for streaming message delivery.

Hi waitingkuo. Thanks for the encouragement. Currently I wouldn't recommend using Drop-In Chat in a production context as the code is too new and not really stable. When we get to the point we think the product is ready for production use we'll make an announcement.

At this point we do not have plans to add video conferencing support.

Thanks for the encouragement. What we have is certainly just a first step. We will continue to keep making incremental improvements now that YC Hacks is over.

Drop-In Chat had a few different XSS flaws. They should all be fixed now. Thanks for finding them and pointing them out!

Sorry for the slow security fix, I was traveling after leaving YC Hacks. Please do let me know if you find anything else wrong.

Thanks for the feedback. Please keep it coming if you think of anything else. We will be prioritizing what to work on.

If you are willing to build on go, we open sourced the "wc" (WebChannel) library which handles all of the messages for dropinchat.

http://gopkg.in/samegoal/wc.v0

Also, out of curiosity, if dropinchat provided a virtual appliance so that you didn't need to send the messages off network would that address your security concerns?

I looked at chatango and I think the intended use case is a bit different than dropinchat. Drop-in chat provides user-to-user instant messaging. As best I can tell, chatango (primarily?) provides broadcast style communication. Is this correct?

Hi, I just checked out interlude. Cool project.

I think the intent of our app is slightly different than yours. Our hope was to allow users of authenticated web applications to chat with one another. Our demo is misleading in this regard as all visitors to dropinchat.com get dropped into a single "chat group" (we din't want users to need to register in order to try it out). We think that apps this product might work well with are enterprise style collaborative applications (where users are already authenticated).

For the time being we are going to keep this completely free to gauge interest. At some point we would likely charge, but at this point don't have solid plans about what the pricing would look like. Sorry I can't be more precise.

Makes sense, thanks for the clarification.

The back end is golang. The client server messaging protocol is BrowserChannel/WebChannel.

https://code.google.com/p/libevent-browserchannel-server/wik...

We open sourced the BrowserChannel library here:

https://github.com/samegoal/wc

And have a chat room demo app here:

https://github.com/samegoal/wcchat

The code we used for this particular site isn't Open Source yet. We are still trying to figure out what we want to do with it before we make that decision.

Thanks Walkman. That is a good idea. We had thought of group chats and chat rooms but a public "broadcast to all" option is interesting too. Kind of like a default room that everyone is in. Is that what you are saying?

Thanks! We will add CSS styling to the configuration options in the DIC variable. Let us know if you think of anything else.