mclifton's comments

DealMe.Cards (http://www.dealme.cards) is a free web app that enables people to play a physical board game they own with their friends over video chat. I developed this with the goal of giving people the ability to feel a small shred of normalcy through the COVID-19 pandemic, by allowing them to perform this classic social activity virtually over the internet.

This is a short video explaining the functionality: https://youtu.be/DoAtHTSuBvs (note that the styling has changed quite a bit since it was shot)

In short, it works like this:

• The host picks and sets up a board game from their collection

• The host can deal out cards to players by using the camera on their phone

• If the cards are meant to be kept secret, the host is able to flip their phone and the card over and snap a picture of it without ever seeing the face of the card

• Players can view a card, highlight it to be played by the host, or show it to all players

• The host can snap an updated view of the game board between each turn

The app itself does not dictate any of the game flow, it simply enables the host and players to participate in a variety of board games by dealing out cards and giving players a few actions that mimic their real life counterparts.

It’s designed for mobile devices, so my apologies if it doesn’t look quite as polished on desktop.

Some ways it differs from other options • The app is entirely free and there is no install

• No advance setup needed (or tools/programming experience)

• It’s designed for mobile

• There is no extra cost depending on the board game you play

Any help in getting the word out would be greatly appreciated! I don’t receive any sort of compensation from its use, but I would love to have some sort of positive effect on people during this time.

A generic communication API (this might exist). When I want to communicate with my customer, it handles how they receive the message - whether that's SMS, Email, IM, slack, etc.

That's how I set up the in-laws laptop with Windows 10. I kept all admin privileges in a separate account with a password only I know. They both get their own unprivileged user accounts, with the standard protections turned on (Firewall, Defender). Haven't had an issue so far, and it's been about 6 months.

I use the Function keys all the time while developing - mostly for debugging.

In IntelliJ, Visual Studio (through Parallels) and Chrome, the Function keys allow me to step through the debugger. It's pretty standard in my day to day workflow, and they all pretty much use the same keys.

Esc is pretty useful in vim and it's used frequently in Windows. I could remap a key, I just don't like being dependent on custom layouts since I sometimes have to switch between machines and I'd rather it be as consistent as possible.

I'm surprised that several people think deleting or even suspending the account is too harsh.

I'm not familiar enough with the nuances of StackOverflow - maybe it would delete other helpful questions and comments he's left in the past if they deleted it, but an indefinite suspension seems very necessary.

How is making a fake post solely for the purpose of advertising your company not against the rules? Even if it's not the letter of the law, how can they afford to tolerate that behavior? The quality of StackOverflow would be severely compromised if this becomes a trend. The internet is full of enough content disguised as original content, SO needs to show that they won't let that happen on their turf.

Did you follow the link sent to your email address? That may be the missing piece. The front page has an example (maybe it shouldn't be actual text, it makes it seem like you can copy it).

Once you use the link that's sent to your email address, you should be able to copy and paste the examples from your personal log-in page.

EDIT: I see why this is confusing, since the textbox doesn't prompt you to submit. I'm adding submit buttons, they'll be up in a few minutes.

SEEKING WORK - Seattle, WA - Remote Ok

Technologies: .NET, JVM (Scala/Java), SQL (SQL Server/Postgres), HTML/CSS/Javascript, Android, DevOps (Chef/Bash)

Recent Projects: https://www.invotes.com, https://www.mytulalipoffers.com, http://www.cinerama.com (updates for client)

Previous Employer: Geocaching.com as a backend API developer.

GitHub: https://github.com/lynx44 LinkedIn: https://www.linkedin.com/in/matt-clifton-127a272b

I'm a full stack Senior Software Developer (10 years), primarily focused in web technologies with mobile experience.

I've developed several complex solutions end to end, and I pick up on new technologies quickly. I tend to follow best practices such as TDD, Continuous Integration and Configuration Management (but I'm adaptable to your organization's needs, I'm not religious).

I'm open to opportunities of all sizes, and I'm available during normal business hours (pacific).

{username}44 at gmail - {replace with HN username}

Thanks so much for the feedback!

Agreed on pretty much all fronts, although you bring up some points I didn't think about.

The icons definitely could use some more explanation. The app does a better job of describing the buttons, and I'd like to eventually update the web to match the same look and feel. A help section and some annotations on the buttons would make things much clearer.

You're right about the slogan, I've changed that several times and can't really decide how to explain it in one catchy sentence. It currently kind of captures the feeling, but it's not really accurate since someone has to make the initial suggestions.

Another good point on providing an email address. To be honest, you previously had to provide everything in the sign up form (first, last and password), so providing only an email address was a more recent improvement. It's nice to have an email address mainly because you could easily lose your administrative link with no way to recover it, plus you receive updates to the event in your inbox. But your point still stands, there's no particular reason why it absolutely has to be required.

I created Invotes to simplify casual hang outs with friends. Being the central decision maker has always been a point of stress for me - my primary goal is to get together with people, whenever it's convenient and wherever they want to go. I always felt there could be a better way to maximize the number of people that could be included.

When you send an invitation with Invotes, it becomes the organizer. It allows guests to suggest and vote on the time and location, then relays updates to every member in your party.

I worked hard to make the invitation process open to everyone. It doesn't matter if they have the app or not, you can contact anyone via SMS, email or in app notification. You can also send a public invitation link after the invitation has been created.

Anyway, I'm happy to have this project off the ground and I'd be excited to hear any feedback or questions. Thanks for checking it out! Any mentions on Facebook/Twitter would be incredible, marketing is not my strong suit.

I've strangely also found that this works the other way as well.

I have strong experience in the .NET ecosystem and good experience with nix platforms and commonly related technologies (including Java and Ruby). When I interviewed for a part time freelance gig with a company on Upwork, they were concerned about my nix experience. They wanted to make sure that since they were a .NET shop, that I wouldn't try to get them to use any non traditional Windows based technologies.

I told them that I'm not partial one way or the other - I just like to use the best tool for the job regardless of where it's hosted. I did end up working for them for a short period of time, but it didn't work out long term.

Scala.js makes sense when everyone on your team works on every level of your stack - generally smaller teams without any specialization.

I'd agree with the other commenters that it makes a lot less sense if you are hiring outside front end devs. You'd probably have a lot less friction if you stick to something more mainstream - either pure Javascript or maybe typescript.

Since my project (https://invotes.com) is a one man operation written purely in Scala at this point, I've used Scala.js on the front end with great results. It's nice to be able to cross compile common functionality between the server, frontend, and Android. I haven't run into any blocking issues between the three platforms. It's also pretty straightforward. I hadn't used Scala at all prior to this project, but most everything makes sense (and I don't even have a problem with SBT).

The biggest downside is the increase in JS size, but at this point it's not too unexpected to have an overall page size at ~1mb, and at least it's all one minified file once it goes to production.

Agreed on the C# front. Outside of implicits, I feel like there was just the occasional google search to find what the equivalent LINQ method was in Scala. It took a couple of days to get it sorted out in my head, but I was able to jump in with Play Framework very quickly since everything was so similar to MVC/C#.

I feel like my experience is quite a bit different. I chose play framework for my web frontend and REST API, and it's quite easy to get started and ship something quickly.

Play framework itself is pretty straightforward with not much in the way of advanced Scala concepts (implicits are probably the most you have to understand). Testing is baked right in and they even handle setting up the application for you in your fixtures.

Coming from the .NET world, it was a huge relief to see that I could just use activator/sbt to compile and publish my artifacts on a build server, just as it works on my local machine. Setting up continuous integration was super easy in comparison to what Microsoft has historically offered (but looks like they're improving with .NET Core).

As for other frameworks and libraries, you may be right on a number of them, but I wouldn't say that all or even most Scala libs are designed to be pure. I have a number of dependencies that are very easy to reason about even if you aren't aware of advanced features.

I'm about to release an app (will probably publish a beta today - https://invotes.com), and it actually works quite well.

The compile times are probably a bit slower than a standard java project, but not bad - something like 5-30 seconds depending on if it's a full rebuild.

I use android-sdk-plugin with SBT along with Scaloid. Wrestling with proguard to hide appropriate warnings can be a little bit of a pain, but even with no prior Android knowledge I was able to figure everything out.

Everything works as expected. There are a few minor issues where Java expects null and that's not normal Scala style, but other than that, nothing important to speak of. My binary builds to 4-5mb.

Prior to reading these arguments I would have agreed. But I suppose I have to admit that I would prefer that someone said "This feature isn't necessary - feature Y is a perfectly good substitute" or even "this feature is inappropriate according to the goals of this project" and upvote those comments, rather than downvoting the original feature/pull request without giving a reason.

I'm not nearly as adamantly opposed to a downvote button, but I can understand the argument.

I love that they're trying to pin this on Venmo, like it's somehow their problem and not a completely misleading article built on misinformation.

> Venmo seems to be confused. According to statement below from Venmo and the message on the developer site, the API is no longer available. But now Venmo tells me the API is still available to existing developers, but not to new ones, which can be a sign of an impending shut down. We’ll update with more info soon once Venmo figures itself out. Parts of this article have been changed for accuracy.

Totally agree. I don't understand what the Scala compile server does. It's far slower than using SBT (or Activator, when working on a Play project).

I always just keep a console open and compile from the command line, because IntelliJ compilation is huge waste of time. I rarely debug because that means I'd have to wait 2 minutes for IntelliJ to do it's thing before it launches.

Oh, and the test output is inconsistent. It often reports that all tests pass even when they are failing.

Other than that - and it is a huge inconvenience - IntelliJ is still awesome for Scala development. Everything else the editor is capable of easily justifies it's place in Scala development.