Friday, July 26, 2024

how to keep django ninja APIs distributed in modules in an apis package?

Hello.

I have decided to use django ninja for its simplicity and performance.

However I have one specific confusion.

Suppose I have an app with a models.py, schemas.py and all my APIs in
one package called apis.

    Suppose in the apis package along with __init__.py I have
api_accounts.py, api_parties.py and api_bills.py with crud functions
decorated with respective get, post ... etc.

Now How all these APIs can be bound together in such a way that they can
be imported in my project's urls.py?

or will there be a differnt way of doing this?

Regards.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/b5f215f2-3a5a-4daf-93c7-ca1f44058fe3%40gmail.com.

Wednesday, July 24, 2024

Django 5.1 release candidate 1 released

Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2024/jul/24/django-51-rc1/

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2BfOnFYZqVJPJVT0_M1O%3D9mt%3D%3Dwfpv3M-RRMzh%2Bb3uOD4xQE8g%40mail.gmail.com.

Monday, July 15, 2024

Re: ComboBox

Hey! Did you ever find a solution to this problem? I found this   https://github.com/trevoreyre/autocomplete/tree/master/packages/autocomplete-js   and it works well : I fill it with > 26,000 choices and it handles it better that anything else I have found.


On Sunday, June 5, 2022 at 4:58:07 AM UTC-5 Phil Parkin wrote:
Thanks for the responses. 
rgam - I appreciate what you are saying. I think it is roughly what I am doing now, but it is a bit clumsy in that  the user (of a financial application) will typically have a list of regular  customers to select from, and also may have other customers that are one-off, or infrequent which they will not want to clutter their options list with but still need to record against a transaction.
Ryan - thanks, the datalist looks like it might be right option. I will look at custom widgets.

All the best - Phil
On Wednesday, 1 June 2022 at 09:13:11 UTC+1 rgam...@gammascience.co.uk wrote:
Hi

If any arbitrary text is allowable, then at the model level I'd just use a CharField. I wouldn't add a choices= argument to the field unless is the value is strictly constrained to those choice as other test would then fail validation.

At the Form level, I'm not sure. I'd probably work just mirror what the frontend needed.

Does that help ?

On Tue, 2022-05-31 at 09:52 -0700, Phil Parkin wrote:
Hi all

I am converting a desktop application to Django web application. The desktop app uses comboboxes (editable dropdown/select). Is their any elegant way of applying the same functionality in Django? Stack Overflow etc. all seem to be about dropdown select lists only.

I can see ways of doing this with a Choicefield plus a separate Charfield, but is there a better way?

Thanks -Phil 

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/1b7836ae-e52e-4e35-aefc-739ce6f586d0n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/268ca0a4-8d95-4560-9e93-eba6a77ce66an%40googlegroups.com.

Sunday, July 14, 2024

Re: Help deciding ORM VS raw SQL trade-off in Complex scenario

Hello,

On Sunday 14 July 2024 at 09:03:38 UTC+2 eric paul wrote:

In whatever way possible use the Django ORM for security purposes and also efficiency .

Offtopic: There are certain issues worth keeping in mind, even if you are using an ORM: https://www.elttam.com/blog/plormbing-your-django-orm/

Cheers,
ReynardSec
https://reynardsec.com/ 

On Sunday 14 July 2024 at 09:03:38 UTC+2 eric paul wrote:

In whatever way possible use the Django ORM for security purposes and also efficiency . I won't recommend to use Raw queries if you don't know what you are doing


On Sun, Jul 14, 2024, 7:34 AM Enock Deghost <enockd...@gmail.com> wrote:

🙄


On Sun, 14 Jul 2024, 6:15 am Krishnakant Mane, <kkpr...@gmail.com> wrote:
Hello.

I am seasoned SQLAlchemy user and quite good in node's sequelise ORM.

But I am new to the one with Django.So here's my situation.

I am developing an accounting (book keeping ) automation software service.

So there are accounting rules (Debit = Dr and credit = Cr) for double
entry book keeping.

Every transaction will have 2 or more amounts, at least 1 each for dr or
Cr.

These entries are called vouchers.

We also store retail bills, receipts and payments again all in different
tables.

But the bills and receipt&payment tables are connected to the voucher
table.

The software generates reports such as cash flow, meaning day's opening
balance, total Drs, total crs, and final closing balance (DRs - Crs).

then there are Profit and Loss as well as balance sheet reports.

All this needs a lot of aggregations (sum and counts ) and also joining
of invoice + voucher and recept&payment + voucher tables.

so here are my questions.

1: given the fact that I have created materialised views in Postgresql,
should I even care to model them and use the ORM syntax instead of raw
query?  What would perform better?

2: datasets are going to be huge some times in terms of shear rows (all
transactions aka vouchers ) or some times sum and count will be used in
complex queries on a huge dataset.

Again, should I rely on raw queries or will ORM plan the queries for me
better?  Should I instead create stored procedures and call them from my
REST API?

talking of which,

3: I am using Django REST Framework and serialising records is an option
to get json output.

Should I use it or just go with raw queries and convert output to JSON
as required?

Again performance is a question.

Tip, My team is very proficient in SQL and yours truely can modestly
call himself an expert in the same, so maintenance is not an issue here.

Regards.

Krishnakant.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/097a6e55-c30e-491e-bf43-86e4c672faa4%40gmail.com.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/019f7cda-12b8-4766-b8cb-6a6ed795b70cn%40googlegroups.com.

Re: Help deciding ORM VS raw SQL trade-off in Complex scenario

According to your scenario an accounting system is a more complex system that requires high performance. It can be written in any language but as the system grows some programming languages will experience performance issues python being one of them take a case like Dropbox which was originally written in python but because of python speeds and data handling limitations it led the team to introduce other languages (Go, Rust) . Since you've decided to go with Django then it's best you use raw queries and concurrency etc inorder to achieve high performance.It also comes down to your hardware and code practices . Take a look at the Django ledger repo an accounting system. About the API you can explore Graphql.


On Sun, Jul 14, 2024, 8:48 PM Krishnakant Mane <kkproghub@gmail.com> wrote:

Hi Eric.

Can you explain a bit more on the "performance " aspect you refered to?

I have already mentioned my scenario and given the case study which I am working on.

In that reference, how using the ORM will benefit more than raw queries working with materialised views?

Regarding security, I (and the team working on this ) are totally aware of the pitfalls and the way around them so that's out of the way.

Regards.

    

On 7/14/24 12:32, eric paul wrote:

In whatever way possible use the Django ORM for security purposes and also efficiency . I won't recommend to use Raw queries if you don't know what you are doing


On Sun, Jul 14, 2024, 7:34 AM Enock Deghost <enockdeghost@gmail.com> wrote:

🙄


On Sun, 14 Jul 2024, 6:15 am Krishnakant Mane, <kkproghub@gmail.com> wrote:
Hello.

I am seasoned SQLAlchemy user and quite good in node's sequelise ORM.

But I am new to the one with Django.So here's my situation.

I am developing an accounting (book keeping ) automation software service.

So there are accounting rules (Debit = Dr and credit = Cr) for double
entry book keeping.

Every transaction will have 2 or more amounts, at least 1 each for dr or
Cr.

These entries are called vouchers.

We also store retail bills, receipts and payments again all in different
tables.

But the bills and receipt&payment tables are connected to the voucher
table.

The software generates reports such as cash flow, meaning day's opening
balance, total Drs, total crs, and final closing balance (DRs - Crs).

then there are Profit and Loss as well as balance sheet reports.

All this needs a lot of aggregations (sum and counts ) and also joining
of invoice + voucher and recept&payment + voucher tables.

so here are my questions.

1: given the fact that I have created materialised views in Postgresql,
should I even care to model them and use the ORM syntax instead of raw
query?  What would perform better?

2: datasets are going to be huge some times in terms of shear rows (all
transactions aka vouchers ) or some times sum and count will be used in
complex queries on a huge dataset.

Again, should I rely on raw queries or will ORM plan the queries for me
better?  Should I instead create stored procedures and call them from my
REST API?

talking of which,

3: I am using Django REST Framework and serialising records is an option
to get json output.

Should I use it or just go with raw queries and convert output to JSON
as required?

Again performance is a question.

Tip, My team is very proficient in SQL and yours truely can modestly
call himself an expert in the same, so maintenance is not an issue here.

Regards.

Krishnakant.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/097a6e55-c30e-491e-bf43-86e4c672faa4%40gmail.com.
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAA2jrmJ0TtbxmfXeSCq5S9p8XsrPjJBf6_gKMRY_MSuTagFt4Q%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CALv%3Dr_nWJjrSk%3DLbFh-pfL5Ni%2B%2ByZu0qH%3DRU7o7mnpD-eJHcqw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CALv%3Dr_mgDtMtaoC-4mav0c79JgH1m-dRC_PL_GU9tVCV8rjypg%40mail.gmail.com.

Re: Help deciding ORM VS raw SQL trade-off in Complex scenario

Bro ,
Just go for it !

On Sun, 14 Jul, 2024, 22:58 Krishnakant Mane, <kkproghub@gmail.com> wrote:

I am looking into ninja too.

I guess I may be able to use SQLAlchemy seamlessly with it.

Regards.

On 7/14/24 21:35, Sam Brown wrote:
Im sure there are performance metrics out there to prove the ORM will not be the bottleneck. But I've never seen it slow things down when I've employed a timer on operation

Also, ive recently ran into some of the limitations of drf and am looking into moving to an api that can be less coupled with orm. Django-ninja looks promising. 

On Sat, Jul 13, 2024 at 9:15 PM Krishnakant Mane <kkproghub@gmail.com> wrote:
Hello.

I am seasoned SQLAlchemy user and quite good in node's sequelise ORM.

But I am new to the one with Django.So here's my situation.

I am developing an accounting (book keeping ) automation software service.

So there are accounting rules (Debit = Dr and credit = Cr) for double
entry book keeping.

Every transaction will have 2 or more amounts, at least 1 each for dr or
Cr.

These entries are called vouchers.

We also store retail bills, receipts and payments again all in different
tables.

But the bills and receipt&payment tables are connected to the voucher
table.

The software generates reports such as cash flow, meaning day's opening
balance, total Drs, total crs, and final closing balance (DRs - Crs).

then there are Profit and Loss as well as balance sheet reports.

All this needs a lot of aggregations (sum and counts ) and also joining
of invoice + voucher and recept&payment + voucher tables.

so here are my questions.

1: given the fact that I have created materialised views in Postgresql,
should I even care to model them and use the ORM syntax instead of raw
query?  What would perform better?

2: datasets are going to be huge some times in terms of shear rows (all
transactions aka vouchers ) or some times sum and count will be used in
complex queries on a huge dataset.

Again, should I rely on raw queries or will ORM plan the queries for me
better?  Should I instead create stored procedures and call them from my
REST API?

talking of which,

3: I am using Django REST Framework and serialising records is an option
to get json output.

Should I use it or just go with raw queries and convert output to JSON
as required?

Again performance is a question.

Tip, My team is very proficient in SQL and yours truely can modestly
call himself an expert in the same, so maintenance is not an issue here.

Regards.

Krishnakant.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/097a6e55-c30e-491e-bf43-86e4c672faa4%40gmail.com.
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CALmEK1sEN%2BLjwcrT-7eYbQkrdkU2bynGehBo4BjvkW1NEBVUjQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/f1a8a082-61c9-449c-9361-d1c8d77c0b07%40gmail.com.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CADg%2BKQth%3DNd593qVO09L%2Bh6GPobPswYO-%3DZDkeXkfZAuWxbR5A%40mail.gmail.com.

Re: Help deciding ORM VS raw SQL trade-off in Complex scenario

I am looking into ninja too.

I guess I may be able to use SQLAlchemy seamlessly with it.

Regards.

On 7/14/24 21:35, Sam Brown wrote:
Im sure there are performance metrics out there to prove the ORM will not be the bottleneck. But I've never seen it slow things down when I've employed a timer on operation

Also, ive recently ran into some of the limitations of drf and am looking into moving to an api that can be less coupled with orm. Django-ninja looks promising. 

On Sat, Jul 13, 2024 at 9:15 PM Krishnakant Mane <kkproghub@gmail.com> wrote:
Hello.

I am seasoned SQLAlchemy user and quite good in node's sequelise ORM.

But I am new to the one with Django.So here's my situation.

I am developing an accounting (book keeping ) automation software service.

So there are accounting rules (Debit = Dr and credit = Cr) for double
entry book keeping.

Every transaction will have 2 or more amounts, at least 1 each for dr or
Cr.

These entries are called vouchers.

We also store retail bills, receipts and payments again all in different
tables.

But the bills and receipt&payment tables are connected to the voucher
table.

The software generates reports such as cash flow, meaning day's opening
balance, total Drs, total crs, and final closing balance (DRs - Crs).

then there are Profit and Loss as well as balance sheet reports.

All this needs a lot of aggregations (sum and counts ) and also joining
of invoice + voucher and recept&payment + voucher tables.

so here are my questions.

1: given the fact that I have created materialised views in Postgresql,
should I even care to model them and use the ORM syntax instead of raw
query?  What would perform better?

2: datasets are going to be huge some times in terms of shear rows (all
transactions aka vouchers ) or some times sum and count will be used in
complex queries on a huge dataset.

Again, should I rely on raw queries or will ORM plan the queries for me
better?  Should I instead create stored procedures and call them from my
REST API?

talking of which,

3: I am using Django REST Framework and serialising records is an option
to get json output.

Should I use it or just go with raw queries and convert output to JSON
as required?

Again performance is a question.

Tip, My team is very proficient in SQL and yours truely can modestly
call himself an expert in the same, so maintenance is not an issue here.

Regards.

Krishnakant.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/097a6e55-c30e-491e-bf43-86e4c672faa4%40gmail.com.
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CALmEK1sEN%2BLjwcrT-7eYbQkrdkU2bynGehBo4BjvkW1NEBVUjQ%40mail.gmail.com.

Je veux de l'aide sur mon erreur pour intégration de paypal

<script>
document.addEventListener("DOMContentLoaded", function() {
const totalAmount = "{{ total|escapejs }}"; // Assurez-vous que 'total' est passé dans le contexte du template

function setupPayPalButton() {
paypal.Buttons({
createOrder: function(data, actions) {
return actions.order.create({
purchase_units: [{
amount: {
value: totalAmount
}
}]
}).then(function(orderID) {
console.log("Order ID: ", orderID);
return orderID;
});
},
onApprove: function(data, actions) {
return actions.order.capture().then(function(details) {
console.log("Order details: ", details);
const orderID = data.orderID; // Order ID
const payerID = details.payer.payer_id; // Payer ID

// Redirection vers la vue payment_done avec les bons paramètres
window.location.href = "{% url 'payment_done' %}?paymentId=" + orderID + "&PayerID=" + payerID;
});
},
onError: function(err) {
console.error('Erreur lors du paiement PayPal:', err);
alert('Erreur lors du paiement PayPal. Veuillez réessayer.');
}
}).render('#payment-buttons-container');
}

function setupCardButton() {
paypal.Buttons({
style: {
label: 'pay',
layout: 'horizontal',
fundingicons: true,
tagline: false
},
createOrder: function(data, actions) {
return actions.order.create({
purchase_units: [{
amount: {
value: totalAmount
}
}]
});
},
onApprove: function(data, actions) {
return actions.order.capture().then(function(details) {
alert('Paiement par carte bancaire effectué avec succès: ' + details.payer.name.given_name);
window.location.href = "{% url 'payment_done' %}?paymentId=" + data.orderID + "&PayerID=" + details.payer.payer_id;
});
},
onError: function(err) {
console.error('Erreur lors du paiement par carte bancaire:', err);
alert('Erreur lors du paiement par carte bancaire. Veuillez réessayer.');
}
}).render('#payment-buttons-container');
}

setupPayPalButton();
});
</script>def execute_payment(request):
payment_id = request.GET.get('paymentId')
payer_id = request.GET.get('PayerID')

payment = paypalrestsdk.Payment.find(payment_id)

if payment.execute({"payer_id": payer_id}):
return redirect(reverse('payment_done') + f'?paymentId={payment_id}&PayerID={payer_id}')
else:
return redirect('payment_cancelled')

@csrf_exempt
def create_payment(request, panier_id):
panier = get_object_or_404(Panier, id=panier_id)

payment = paypalrestsdk.Payment({
"intent": "sale",
"payer": {
"payment_method": "paypal"
},
"redirect_urls": {
"return_url": request.build_absolute_uri(reverse('payment_done')),
"cancel_url": request.build_absolute_uri(reverse('payment_cancelled'))
},
"transactions": [{
"item_list": {
"items": [{
"name": "Panier",
"sku": "panier",
"price": str(panier.get_total()),
"currency": "USD",
"quantity": 1
}]
},
"amount": {
"total": str(panier.get_total()),
"currency": "USD"
},
"description": f"Paiement pour le panier {panier.id}"
}]
})

if payment.create():
for link in payment.links:
if link.rel == "approval_url":
approval_url = link.href
return JsonResponse({'approval_url': approval_url})
else:
return JsonResponse({'error': payment.error}, status=500)

def payment_view(request):
panier = Panier.objects.get(client=request.user)
total = panier.get_total()

payment = paypalrestsdk.Payment({
"intent": "sale",
"payer": {
"payment_method": "paypal"},
"redirect_urls": {
"return_url": request.build_absolute_uri(reverse('payment_done')),
"cancel_url": request.build_absolute_uri(reverse('payment_cancelled'))},
"transactions": [{
"item_list": {
"items": [{
"name": "Total Order",
"sku": "001",
"price": str(total),
"currency": "USD",
"quantity": 1}]},
"amount": {
"total": str(total),
"currency": "USD"},
"description": "Payment for order"}]})

if payment.create():
for link in payment.links:
if link.method == "REDIRECT":
redirect_url = link.href
return redirect(redirect_url)
else:
print(payment.error)
return redirect('payment_cancelled')

@login_required
def payment_done(request):
payment_id = request.GET.get('paymentId')
payer_id = request.GET.get('PayerID')

print(f"Payment ID: {payment_id}, Payer ID: {payer_id}")

if not payment_id or not payer_id:
return redirect('payment_cancelled')

try:
payment = paypalrestsdk.Payment.find(payment_id)
print(f"Payment found: {payment}")

if payment.execute({"payer_id": payer_id}):
panier = Panier.objects.get(client=request.user, status='en cours')
panier.Commander = True
panier.status = 'completé'
panier.save()
for commande in panier.commandes.all():
commande.commander = True
commande.save()

adresse_facturation = AdresseFacturation.objects.filter(client=request.user).last()

context = {
'payment': payment,
'adresse_facturation': adresse_facturation,
'commandes': panier.commandes.all(),
'total': panier.get_total()
}

return render(request, 'payment_done.html', context)
else:
print("Payment execution failed")
print(f"Payment error: {payment.error}")
return redirect('payment_cancelled')
except paypalrestsdk.ResourceNotFound as error:
print(f"Payment not found: {error}")
return redirect('payment_cancelled')
except Exception as e:
print(f"Unexpected error: {e}")
return redirect('payment_cancelled')




def payment_cancelled(request):
return render(request, 'e_commerce/payment_cancelled.html')class Commande(models.Model):
"""
Modèle représentant une commande passée par un utilisateur.
"""
client = models.ForeignKey(Client, on_delete=models.CASCADE, null=True, blank=True)
visitor_id = models.CharField(max_length=36, null=True, blank=True)
produit = models.ForeignKey(Produit, on_delete=models.CASCADE)
quantite = models.IntegerField(default=1)
sous_total = models.DecimalField(max_digits=10, decimal_places=2, default=0)
taille = models.CharField(max_length=20, choices=Produit.CHOIX_TAILLE, null=True, blank=True)
couleurs = models.ForeignKey(Couleur, on_delete=models.SET_NULL, related_name='commandes', blank=True, null=True)
commander = models.BooleanField(default=False)
created_de_creation = models.DateTimeField(auto_now_add=True)
updated_at = models.DateTimeField(auto_now=True)

def __str__(self) -> str:
return f'{self.produit.nom} ({self.quantite})'

def save(self, *args, **kwargs):
self.sous_total = self.produit.prix * self.quantite
super().save(*args, **kwargs)

class AdresseFacturation(models.Model):
client = models.ForeignKey(Client, on_delete=models.SET_NULL, blank=True, null=True)
commande = models.ForeignKey(Commande, on_delete=models.SET_NULL, blank=True, null=True)
addresse = models.CharField(max_length=100, null=True)
ville = models.CharField(max_length=100, null=True)
zipcode = models.CharField(max_length=100, null=True)
date_ajout = models.DateTimeField(auto_now_add=True)

def __str__(self):
return self.addresse

class Panier(models.Model):
"""
Modèle représentant le panier d'un utilisateur.
"""
STATUS_CHOICES = [
('en cours', 'En cours'),
('completé', 'Completé'),
('annulé', 'Annulé'),
]

visitor_id = models.CharField(max_length=36, null=True, blank=True)
client = models.ForeignKey(Client, on_delete=models.CASCADE, null=True, blank=True)
commandes = models.ManyToManyField(Commande)
total = models.DecimalField(max_digits=10, decimal_places=2, default=0)
Commander = models.BooleanField(default=False)
status = models.CharField(max_length=20, choices=STATUS_CHOICES, default='en cours')
created_de_creation = models.DateTimeField(auto_now_add=True)

def __str__(self):
if self.client:
return f"{self.client.nom} Panier"
else:
return f"Panier {self.visitor_id}"

def get_total(self):
total = sum(commande.sous_total for commande in self.commandes.all())
return total
Payment ID: 1L942492VB111070T, Payer ID: FVXL22PYEGX8J Payment not found: Failed. Response status: 404. Response message: Not Found. Error message: {"name":"INVALID_RESOURCE_ID","message":"Requested resource ID was not found.","information_link":"https://developer.paypal.com/docs/api/payments/#errors","debug_id":"56e42beeb4a02"} [14/Jul/2024 17:17:05] "GET /payment-done/?paymentId=1L942492VB111070T&PayerID=FVXL22PYEGX8J HTTP/1.1" 302 0

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CANN1LxORNTPeSN83oafvv6cnTX1gbTKvJQM2kUX9ePKyjaCNZw%40mail.gmail.com.

Re: Help deciding ORM VS raw SQL trade-off in Complex scenario

Im sure there are performance metrics out there to prove the ORM will not be the bottleneck. But I've never seen it slow things down when I've employed a timer on operation

Also, ive recently ran into some of the limitations of drf and am looking into moving to an api that can be less coupled with orm. Django-ninja looks promising. 

On Sat, Jul 13, 2024 at 9:15 PM Krishnakant Mane <kkproghub@gmail.com> wrote:
Hello.

I am seasoned SQLAlchemy user and quite good in node's sequelise ORM.

But I am new to the one with Django.So here's my situation.

I am developing an accounting (book keeping ) automation software service.

So there are accounting rules (Debit = Dr and credit = Cr) for double
entry book keeping.

Every transaction will have 2 or more amounts, at least 1 each for dr or
Cr.

These entries are called vouchers.

We also store retail bills, receipts and payments again all in different
tables.

But the bills and receipt&payment tables are connected to the voucher
table.

The software generates reports such as cash flow, meaning day's opening
balance, total Drs, total crs, and final closing balance (DRs - Crs).

then there are Profit and Loss as well as balance sheet reports.

All this needs a lot of aggregations (sum and counts ) and also joining
of invoice + voucher and recept&payment + voucher tables.

so here are my questions.

1: given the fact that I have created materialised views in Postgresql,
should I even care to model them and use the ORM syntax instead of raw
query?  What would perform better?

2: datasets are going to be huge some times in terms of shear rows (all
transactions aka vouchers ) or some times sum and count will be used in
complex queries on a huge dataset.

Again, should I rely on raw queries or will ORM plan the queries for me
better?  Should I instead create stored procedures and call them from my
REST API?

talking of which,

3: I am using Django REST Framework and serialising records is an option
to get json output.

Should I use it or just go with raw queries and convert output to JSON
as required?

Again performance is a question.

Tip, My team is very proficient in SQL and yours truely can modestly
call himself an expert in the same, so maintenance is not an issue here.

Regards.

Krishnakant.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/097a6e55-c30e-491e-bf43-86e4c672faa4%40gmail.com.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CALmEK1sEN%2BLjwcrT-7eYbQkrdkU2bynGehBo4BjvkW1NEBVUjQ%40mail.gmail.com.

Re: Help deciding ORM VS raw SQL trade-off in Complex scenario

In whatever way possible use the Django ORM for security purposes and also efficiency . I won't recommend to use Raw queries if you don't know what you are doing


On Sun, Jul 14, 2024, 7:34 AM Enock Deghost <enockdeghost@gmail.com> wrote:

🙄


On Sun, 14 Jul 2024, 6:15 am Krishnakant Mane, <kkproghub@gmail.com> wrote:
Hello.

I am seasoned SQLAlchemy user and quite good in node's sequelise ORM.

But I am new to the one with Django.So here's my situation.

I am developing an accounting (book keeping ) automation software service.

So there are accounting rules (Debit = Dr and credit = Cr) for double
entry book keeping.

Every transaction will have 2 or more amounts, at least 1 each for dr or
Cr.

These entries are called vouchers.

We also store retail bills, receipts and payments again all in different
tables.

But the bills and receipt&payment tables are connected to the voucher
table.

The software generates reports such as cash flow, meaning day's opening
balance, total Drs, total crs, and final closing balance (DRs - Crs).

then there are Profit and Loss as well as balance sheet reports.

All this needs a lot of aggregations (sum and counts ) and also joining
of invoice + voucher and recept&payment + voucher tables.

so here are my questions.

1: given the fact that I have created materialised views in Postgresql,
should I even care to model them and use the ORM syntax instead of raw
query?  What would perform better?

2: datasets are going to be huge some times in terms of shear rows (all
transactions aka vouchers ) or some times sum and count will be used in
complex queries on a huge dataset.

Again, should I rely on raw queries or will ORM plan the queries for me
better?  Should I instead create stored procedures and call them from my
REST API?

talking of which,

3: I am using Django REST Framework and serialising records is an option
to get json output.

Should I use it or just go with raw queries and convert output to JSON
as required?

Again performance is a question.

Tip, My team is very proficient in SQL and yours truely can modestly
call himself an expert in the same, so maintenance is not an issue here.

Regards.

Krishnakant.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/097a6e55-c30e-491e-bf43-86e4c672faa4%40gmail.com.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAA2jrmJ0TtbxmfXeSCq5S9p8XsrPjJBf6_gKMRY_MSuTagFt4Q%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CALv%3Dr_nWJjrSk%3DLbFh-pfL5Ni%2B%2ByZu0qH%3DRU7o7mnpD-eJHcqw%40mail.gmail.com.

Saturday, July 13, 2024

Re: Help deciding ORM VS raw SQL trade-off in Complex scenario

If you use ORM QUERY THEN IT IS VERY EASY TO SOLVE THIS ONE BY USING FOREIGN KEY OR MANY TO MANY RELATIONSHIP AND WHEN IF USER NOT RAGISTER THEN WE NEED TO ADD NON RAGISTER USER UNIQUE KEY FOR IDENTIFICATION AND AMOUNT WHICH ONE TAKE RECIEVE THE MONEY STORED IDENTIFICATION KEY  IN PAYMENT TABLE AND CONNECT MORE TABLE


On Sun, 14 Jul, 2024, 10:05 AM Enock Deghost, <enockdeghost@gmail.com> wrote:

🙄


On Sun, 14 Jul 2024, 6:15 am Krishnakant Mane, <kkproghub@gmail.com> wrote:
Hello.

I am seasoned SQLAlchemy user and quite good in node's sequelise ORM.

But I am new to the one with Django.So here's my situation.

I am developing an accounting (book keeping ) automation software service.

So there are accounting rules (Debit = Dr and credit = Cr) for double
entry book keeping.

Every transaction will have 2 or more amounts, at least 1 each for dr or
Cr.

These entries are called vouchers.

We also store retail bills, receipts and payments again all in different
tables.

But the bills and receipt&payment tables are connected to the voucher
table.

The software generates reports such as cash flow, meaning day's opening
balance, total Drs, total crs, and final closing balance (DRs - Crs).

then there are Profit and Loss as well as balance sheet reports.

All this needs a lot of aggregations (sum and counts ) and also joining
of invoice + voucher and recept&payment + voucher tables.

so here are my questions.

1: given the fact that I have created materialised views in Postgresql,
should I even care to model them and use the ORM syntax instead of raw
query?  What would perform better?

2: datasets are going to be huge some times in terms of shear rows (all
transactions aka vouchers ) or some times sum and count will be used in
complex queries on a huge dataset.

Again, should I rely on raw queries or will ORM plan the queries for me
better?  Should I instead create stored procedures and call them from my
REST API?

talking of which,

3: I am using Django REST Framework and serialising records is an option
to get json output.

Should I use it or just go with raw queries and convert output to JSON
as required?

Again performance is a question.

Tip, My team is very proficient in SQL and yours truely can modestly
call himself an expert in the same, so maintenance is not an issue here.

Regards.

Krishnakant.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/097a6e55-c30e-491e-bf43-86e4c672faa4%40gmail.com.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAA2jrmJ0TtbxmfXeSCq5S9p8XsrPjJBf6_gKMRY_MSuTagFt4Q%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFqcJsm2GnNQCXf2t%3DETH0RXX7vBqcijB6OgP6o5CK7ocfXzyA%40mail.gmail.com.

Re: Help deciding ORM VS raw SQL trade-off in Complex scenario

🙄


On Sun, 14 Jul 2024, 6:15 am Krishnakant Mane, <kkproghub@gmail.com> wrote:
Hello.

I am seasoned SQLAlchemy user and quite good in node's sequelise ORM.

But I am new to the one with Django.So here's my situation.

I am developing an accounting (book keeping ) automation software service.

So there are accounting rules (Debit = Dr and credit = Cr) for double
entry book keeping.

Every transaction will have 2 or more amounts, at least 1 each for dr or
Cr.

These entries are called vouchers.

We also store retail bills, receipts and payments again all in different
tables.

But the bills and receipt&payment tables are connected to the voucher
table.

The software generates reports such as cash flow, meaning day's opening
balance, total Drs, total crs, and final closing balance (DRs - Crs).

then there are Profit and Loss as well as balance sheet reports.

All this needs a lot of aggregations (sum and counts ) and also joining
of invoice + voucher and recept&payment + voucher tables.

so here are my questions.

1: given the fact that I have created materialised views in Postgresql,
should I even care to model them and use the ORM syntax instead of raw
query?  What would perform better?

2: datasets are going to be huge some times in terms of shear rows (all
transactions aka vouchers ) or some times sum and count will be used in
complex queries on a huge dataset.

Again, should I rely on raw queries or will ORM plan the queries for me
better?  Should I instead create stored procedures and call them from my
REST API?

talking of which,

3: I am using Django REST Framework and serialising records is an option
to get json output.

Should I use it or just go with raw queries and convert output to JSON
as required?

Again performance is a question.

Tip, My team is very proficient in SQL and yours truely can modestly
call himself an expert in the same, so maintenance is not an issue here.

Regards.

Krishnakant.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/097a6e55-c30e-491e-bf43-86e4c672faa4%40gmail.com.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAA2jrmJ0TtbxmfXeSCq5S9p8XsrPjJBf6_gKMRY_MSuTagFt4Q%40mail.gmail.com.

Help deciding ORM VS raw SQL trade-off in Complex scenario

Hello.

I am seasoned SQLAlchemy user and quite good in node's sequelise ORM.

But I am new to the one with Django.So here's my situation.

I am developing an accounting (book keeping ) automation software service.

So there are accounting rules (Debit = Dr and credit = Cr) for double
entry book keeping.

Every transaction will have 2 or more amounts, at least 1 each for dr or
Cr.

These entries are called vouchers.

We also store retail bills, receipts and payments again all in different
tables.

But the bills and receipt&payment tables are connected to the voucher
table.

The software generates reports such as cash flow, meaning day's opening
balance, total Drs, total crs, and final closing balance (DRs - Crs).

then there are Profit and Loss as well as balance sheet reports.

All this needs a lot of aggregations (sum and counts ) and also joining
of invoice + voucher and recept&payment + voucher tables.

so here are my questions.

1: given the fact that I have created materialised views in Postgresql,
should I even care to model them and use the ORM syntax instead of raw
query?  What would perform better?

2: datasets are going to be huge some times in terms of shear rows (all
transactions aka vouchers ) or some times sum and count will be used in
complex queries on a huge dataset.

Again, should I rely on raw queries or will ORM plan the queries for me
better?  Should I instead create stored procedures and call them from my
REST API?

talking of which,

3: I am using Django REST Framework and serialising records is an option
to get json output.

Should I use it or just go with raw queries and convert output to JSON
as required?

Again performance is a question.

Tip, My team is very proficient in SQL and yours truely can modestly
call himself an expert in the same, so maintenance is not an issue here.

Regards.

Krishnakant.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/097a6e55-c30e-491e-bf43-86e4c672faa4%40gmail.com.

Wednesday, July 10, 2024

Re: Reactive frontend + Session Authentication (+ csrf ?)

Hi Zvo,

The moment you decide to isolate Frontend from Backend, 
you must decide how you would like to host them, i.e. the endpoints for frontend and backend.

You have two options here
  1. host both the frontend and backend under the same domain with reverse proxy configuration
  2. host front end in a domain and backend in another domain
In case of option 1 (front end and backend hosted under the same domain) you can manage to use session authentication.
You could design the login form in Django and redirect to the frontend url upon successful login.
You need not have to worry about CORS Cross Origin Resource Sharing since both FE and BE are under the same domain.
Both the session and csrf cookie will automatically be attached to all your requests from FE.

In case of option2, you cannot use session authentication since session cookies are domain specific.
You have to resort to JWT or OAUTH2.0 (which in turn are based on jwt) for authentication.
I recommend starting out with Django Rest Framework Simple JWT along with Django REST Framework.

If you search for if JWT is secure, you will get responses like it is not as secure as session authentication.
It is still the methodology used in most of the applications which has a dedicated frontend.

I would recommend you to reconsider your backend technology choice.  
This is because, when you decide to isolate frontend from backend, you lose most of the "Batteries included" in Django.
You are not going to use Forms, Templates, Tables and Authentication.  
That is pretty much all the good stuffs that Django offers.
If I were in your situation, I would use FastAPI for backend.

Thanks,
SWARUP Selvaraj
On Monday 20 May 2024 at 20:39:08 UTC+5:30 zvo...@seznam.cz wrote:
With traditional frontend (like realized with Django templates), the user will GET the login form and in this step Django sends csrf token. Later, in 2nd step, you send credential and the csrf token to the server.

But in Django + Reactive frontend (Svelte in my case, but it is not important at all) solution, the Login form is created by Svelte. Them submission: not the real submission, but under the Submit button Svelte sends credentials to Django using FetchAPI. Maybe this submission is the 1st communication to Django server and so we haven't the csrf token yet (?!)

So I have realized the Session Authentication without any regard to csrftoken cookie. My login view is wrapped by csrf_exempt. Svelte form sends credentials, Django makes login() and sends sessionid cookie back. It works.

Now my question is: Is this solution safe enough? Or is it danger and I should first get the csrftoken cookie from server in some earlier request and add the header with csrftoken?

It is pain to have such question.
AI cannot answer it, instead it will write lot of text and code examples, without answering YES or NO, without understanding what I am asking.
Find other sources is difficult (StackOverflow) is difficult too. On one side many people say Session Authentication is safe for browsers, JWT is not safe at all (because the token is saved in LocalStorage, not KeyChain). On other side, it looks like almost nobody uses Session Authentication and in problems many people say: Just go to JWT.
That are reasons why it is difficult to realize the Session Authentication. But once realized, it is supereasy - no code, just the built-in cookie mechanism.

So what do you mean?
Or can you recommend some source which describes reactive frontend + sessionid & csrftoken cookies?

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/0d969dd7-b76e-400a-81b4-8fd7312ac115n%40googlegroups.com.

Saturday, July 6, 2024

Re: Freelance Opportunity : Django Developer for building A Dialer

Let's chat! https://www.linkedin.com/in/jayesh-bafna-bb24aa13a/

On Tuesday 2 April 2024 at 20:03:47 UTC+2 gethsun misesi wrote:
Hey Abhishek,

Thank you for reaching out and considering me for this exciting opportunity to work on the development of an Android and iOS phone dialer app similar to Truecaller.

I am a dedicated and experienced Django developer with a strong passion for creating innovative solutions, particularly within the education sector. I believe my skills and expertise align well with the requirements of this project.

I am eager to collaborate with your team and contribute to this impactful initiative. Please let me know the next steps in the process, such as providing more details about the project scope, timeline, and any specific technical requirements.

Looking forward to the opportunity to work together.

Best regards,
Gethsun

GETHSUN MISESI

Young Leader


Nairobi Garage | Ngong Road | Nairobi | Kenya

Mobile +254 721913191, +254 7821913191

gethsun09@gmail.com


The Race is not for the swift, but those who can endure it



On Tue, Apr 2, 2024 at 8:19 PM Abhishek J <Abhishek@assureassistance.in> wrote:
Dear Developers,

I need to build an android and IOS phone dialer similar to Truecaller.

We are seeking experienced and dedicated candidates who are proficient in Django and possess a keen interest in contributing to this impactful initiative.

We look forward to the opportunity to collaborate with talented individuals who are passionate about creating innovative solutions in the education sector.

Thank you for considering this opportunity.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAKkngwDHBygGho4gkHRhNkpVJf_d2UOkHQ%3DemN3BtcFSVRU8sA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/157f63a4-3132-4ff7-b79d-699dd29e58een%40googlegroups.com.

Monday, July 1, 2024

Re: Candidacy for the Contract Full Stack Django Engineer role

It is okay!

On Sun, 30 Jun 2024 at 06:20, Gobi Dasu <gobi@gobidasu.com> wrote:
I am so sorry for sending this to the wrong email address. Please forgive me. I meant to send it to the individual.

On Sat, Jun 29, 2024 at 11:18 PM <gobi@gobidasu.com> wrote:
Hi Bernard,

We commend your dedication to pioneering AI-enabled systems through advanced Django development, reflecting a strong commitment to technological innovation and excellence.

I saw your job post for the Contract Full Stack Django Engineer role at your endeavor. I (Gobi) personally would be interested in working with you as an IC or PM. Here is my profile.

If I'm not the right fit, then my peers, these candidates from our network, may be relevant to your search for talent who know Django, CSS, Continuous Integration, NoSQL, and Stripe API. We recommend checking out Gobi D, Collins M and Wilfred Chetat Y (myself included).

My peers and I work through LD Talent, a future of work platform that has helped 100+ remote teams quickly find vetted, motivated, and productive talent.

Teams hiring on LD Talent include startups funded by Y Combinator and 500 Global, tech giants like Baidu and Infosys, and universities like Yale and Northwestern.

Free Trial: We give out ~5 free hours to try us before hiring us for contract or full-time roles. To see how incredibly unique LD is, check out this video: https://www.youtube.com/watch?v=EVAo8LPCZmA

Mission: To strengthen remote teams by helping them drop location constraints and include qualified but overlooked talent from the majority world: diversity meets capitalism.

Contact: We split our time between WI USA, Stanford, CA USA, Northwestern, IL USA, and on occasion Africa, India, and Nepal. If you have any questions, you can connect with us on LinkedIn (profiles in the signature below) or schedule a call: our calendar

Regards,
Gobi, alongside Anisha, Girija, and Nutan
Stanford CS · Northwestern HCI · IITD · UCSC
Calendar · PM Service · Join our Investors


10311 Sister Oak Dr. Verona, WI USA 53593 · +14087055753 (SMS only) · Unsubscribe

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAMk8evkJgyw_-UNvNqFQF3mWN%3D-bcg%2BWd7j255G80Nneg9zvkw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAKMmiN21K%3DNt_01d7kQ%3DLevY6Ytdd5PrJ7j-fgF5P3phLKH9xQ%40mail.gmail.com.

Saturday, June 29, 2024

Re: Candidacy for the Contract Full Stack Django Engineer role

I am so sorry for sending this to the wrong email address. Please forgive me. I meant to send it to the individual.

On Sat, Jun 29, 2024 at 11:18 PM <gobi@gobidasu.com> wrote:
Hi Bernard,

We commend your dedication to pioneering AI-enabled systems through advanced Django development, reflecting a strong commitment to technological innovation and excellence.

I saw your job post for the Contract Full Stack Django Engineer role at your endeavor. I (Gobi) personally would be interested in working with you as an IC or PM. Here is my profile.

If I'm not the right fit, then my peers, these candidates from our network, may be relevant to your search for talent who know Django, CSS, Continuous Integration, NoSQL, and Stripe API. We recommend checking out Gobi D, Collins M and Wilfred Chetat Y (myself included).

My peers and I work through LD Talent, a future of work platform that has helped 100+ remote teams quickly find vetted, motivated, and productive talent.

Teams hiring on LD Talent include startups funded by Y Combinator and 500 Global, tech giants like Baidu and Infosys, and universities like Yale and Northwestern.

Free Trial: We give out ~5 free hours to try us before hiring us for contract or full-time roles. To see how incredibly unique LD is, check out this video: https://www.youtube.com/watch?v=EVAo8LPCZmA

Mission: To strengthen remote teams by helping them drop location constraints and include qualified but overlooked talent from the majority world: diversity meets capitalism.

Contact: We split our time between WI USA, Stanford, CA USA, Northwestern, IL USA, and on occasion Africa, India, and Nepal. If you have any questions, you can connect with us on LinkedIn (profiles in the signature below) or schedule a call: our calendar

Regards,
Gobi, alongside Anisha, Girija, and Nutan
Stanford CS · Northwestern HCI · IITD · UCSC
Calendar · PM Service · Join our Investors


10311 Sister Oak Dr. Verona, WI USA 53593 · +14087055753 (SMS only) · Unsubscribe

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAMk8evkJgyw_-UNvNqFQF3mWN%3D-bcg%2BWd7j255G80Nneg9zvkw%40mail.gmail.com.

Candidacy for the Contract Full Stack Django Engineer role

Hi Bernard,

We commend your dedication to pioneering AI-enabled systems through advanced Django development, reflecting a strong commitment to technological innovation and excellence.

I saw your job post for the Contract Full Stack Django Engineer role at your endeavor. I (Gobi) personally would be interested in working with you as an IC or PM. Here is my profile.

If I'm not the right fit, then my peers, these candidates from our network, may be relevant to your search for talent who know Django, CSS, Continuous Integration, NoSQL, and Stripe API. We recommend checking out Gobi D, Collins M and Wilfred Chetat Y (myself included).

My peers and I work through LD Talent, a future of work platform that has helped 100+ remote teams quickly find vetted, motivated, and productive talent.

Teams hiring on LD Talent include startups funded by Y Combinator and 500 Global, tech giants like Baidu and Infosys, and universities like Yale and Northwestern.

Free Trial: We give out ~5 free hours to try us before hiring us for contract or full-time roles. To see how incredibly unique LD is, check out this video: https://www.youtube.com/watch?v=EVAo8LPCZmA

Mission: To strengthen remote teams by helping them drop location constraints and include qualified but overlooked talent from the majority world: diversity meets capitalism.

Contact: We split our time between WI USA, Stanford, CA USA, Northwestern, IL USA, and on occasion Africa, India, and Nepal. If you have any questions, you can connect with us on LinkedIn (profiles in the signature below) or schedule a call: our calendar

Regards,
Gobi, alongside Anisha, Girija, and Nutan
Stanford CS · Northwestern HCI · IITD · UCSC
Calendar · PM Service · Join our Investors


10311 Sister Oak Dr. Verona, WI USA 53593 · +14087055753 (SMS only) · Unsubscribe

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAMk8ev%3DbXDFtdOn3FX-k07HOiocqyv%3DDKAsGUkmiF_E8dNBi3Q%40mail.gmail.com.