Vadim Galygin

@Cerberus I agree, but 2 in transit statuses are more ambiguous I think

For pending I see alternative as expected (?)

Each user has his own panel, where he adds packages, and can see all information about them

Well, my problem is the names for these statuses: pending (?), arrived (office is very good), delivered (??? picked up is better I think, but still not 100% sure)

so it will be more like: Package.in_transit, Package.warehouse, etc.

I want to have all status info in one field called status

status names are too long, because for first two I have prefix, and it is something like: status_warehouse_in_transit, status_warehouse_delivered, and for the latter 2 I use different field to track the status

yes, but it is pain to work with when writing code

Currently we have something like: in_transit_to_warehouse, warehouse_delivered, in_transit_to_city_name, delivered

No, for other countries we just use copy of the system with different domain and design

So they are easy to understand

I want short names, like 1-2 words, or 3 short words

to something like in transit to country of destination (but this is bad, because all users are from 1 country, there won't be any other destinations)

yes, but if i change it from Pending to In transit to U.S. warehouse, I also need to update original in transit status

It is in transit by USPS, UPS or FedEx from Amazon for example to our US warehouse

I like the office instead of arrived, maybe even used as arrived to office

And there are few others such as pending (waiting for package to arrive at warehouse), warehouse (packages arrived to our warehouse), processing (packages are being repacked / we make photos of contents, etc), in transit (sent from US warehouse to country where office and all users located), then arrived, delivered

These statuses are shown in user's dashboard

Can I name them differently? Or current naming is fine?

I have a problem with naming stuff. There are 2 types of packages in package forwarding system, one is for packages delivered to office (arrived) and second is for packages that users picked up (delivered)

hello everyone!

@Mr.ShinyandNew安宇 oh, this is bad thing. Sorry I'm not good in politics

I think China is a lot more dangerous for US than Russia

Economy is 10,000 times weaker than US

Why everyone is talking about Russia everywhere? They have nothing but nuclear weapon

Can we have some alternative for PackageDescriptionSuggestions? I like it, but it is much longer than all my other models :(

you will be a lot more happier if bad things not happen in production

so try to avoid this as much as you can

@Cerberus something like media.giphy.com/media/XjlNyeZp5lDri/giphy.gif

and it is a HELL

@Cerberus I do support some old project deploying code right to production, we are rewriting the system now

@Mr.ShinyandNew安宇 oops :D

@Cerberus its up to you, better stick with good practices, it will make your work easier and more error prone

So it is very simple to make local environment

Sooner or later you will hit yourself in a knee with this workflow

You should use local or stage server to make changes, test, then deploy

Or possible data corruption if you mess with models

Any mistake - your users get errors

All of your edits are always run on production

I used to do so, some old days. This is bad.

You can't revert back

You don't have any file history to track your changes

What if you make some edit and only after a week discover some bug?

@Cerberus this is bad practice

@Cerberus great! use git to backup your files and you are done :)

for images you should use something like AWS S3

only applicable to code, images not good for it

you will have all file history, and won't lose it

host your files with git on something like gitlab or bitbucket

what if server dies?