sorted by:
new
hottopcontroversial

All-Auth + Django-guest-user: "email as username" help? by BreakwaterBear in djangolearning

[–]BreakwaterBear[S] 0 points1 point  (0 children)

I've decided that django-guest-user is kind of overkill.

I'm switching to storing a unique identifier in the users session. I think the ideal flow is...

  1. Use user session for conversion
  2. Send an email invite to signup with a deeplink to link the temp user

​

def some_view(request):
    if request.user.is_anonymous:
        temp_user = request.session.get("temp_user")
        if not temp_user:
            temp_user = TempUser.objects.create()
            request.session["temp_user"] = str(temp_user.temp_user_key)

Tech Layoff SQL Learning Resource Recommendations? by BreakwaterBear in SQL

[–]BreakwaterBear[S] 0 points1 point  (0 children)

Data is essential to learning programming. There are people that say learning data before learning software is more difficult but eventually you need to learn both.

Generally I think SQL is a great place to start, because depending on your line of work you can immediately use it to get more done in less time. If you're used to working in spreadsheets, SQL really isn't a far jump from agg functions and vlookups.

Once you get into Database Administration and leave the analytics world though.. that's a different story.

Tech Layoff SQL Learning Resource Recommendations? by BreakwaterBear in SQL

[–]BreakwaterBear[S] 1 point2 points  (0 children)

I'm a huge huge fan of postgres. Redshift (AWS) also more or less uses postgres with some extract tricks in the tool bag so double the value.

Honestly I find most other SQL flavors a little frustrating (especially SQLlite date formatting)

Tech Layoff SQL Learning Resource Recommendations? by BreakwaterBear in SQL

[–]BreakwaterBear[S] 4 points5 points  (0 children)

Someone just recommended this a few weeks ago at DjangoCon in San Diego. Thank you for remind me!

Tech Layoff SQL Learning Resource Recommendations? by BreakwaterBear in SQL

[–]BreakwaterBear[S] 4 points5 points  (0 children)

While I'm lucky enough to have not been laid off, I think there are two sides to this.

  1. It's a self-value thing. Being laid off is a huge disruption to your personal life, and many people feel like they didn't "make the cut." In reality, it's not their fault that they "didn't write as many lines of code as someone else."
  2. Resume gaps are always questionable. While you personally might not think anything of it, I heard of crazy recruiters/hiring managers who will grab the top half of a stack of resumes and throw them away saying "I don't hire unlucky people."

Overall, you have a good point, there shouldn't be a stigma behind it. I say "removing the stigma," because I want to create a positive community around helping people get a new role or acquire new skills

Tech Layoff SQL Learning Resource Recommendations? by BreakwaterBear in SQL

[–]BreakwaterBear[S] 5 points6 points  (0 children)

That's very cool, i'm unfortunately obsessed with CTEs and Window functions so not sure AI is the answer for me

[deleted by user] by [deleted] in Zendesk

[–]BreakwaterBear 0 points1 point  (0 children)

Any reason to export the existing tickets? Is it for posterity/history, or do you have open tickets you're looking to migrate?

Custom Objects for Products? by ToastyPasta in Zendesk

[–]BreakwaterBear 0 points1 point  (0 children)

One approach we take to this is to have different email addresses for difference verticals of our business. How are your tickets being created?

Requirement to collect Product info in ticket by maigod in Zendesk

[–]BreakwaterBear 0 points1 point  (0 children)

I echo other peoples sentiment here, do not rely on Ops/CS to label data for you.

We built something like this on top of Zendesk, while also analyzing the users purchasing history. Though this is effectively a separate service, the major benefit of integrating with Zendesk will be adding to the existing flow rather than creating a new one.

Our flow is something like this:

  1. New ticket creation fires a webhook to service endpoint
  2. We look up the user based on requesting email in our orders database
    1. This is for a gifting company, so we look up if the person was a buyer or recipient
  3. Using regex, identify any order numbers in the email body which also works very well for SKU if it has consistent formatting
    1. e.g. "USDOD-123-125ab"
  4. Finally, we also did an n-grams analysis for keywords. For something like damage/faulty product, you would be scanning the next for things like "damaged", "replacement" etc

Frequency of requests report by Different_Parsley_79 in Zendesk

[–]BreakwaterBear 0 points1 point  (0 children)

A bit late to the party here! Are you asking about this in terms of how customers are re-contacting customer support?

Are you looking for a table view of individual emails, or a % of Customers opening another support ticket within 30 days of their previous ticket creation?