Yes, you're right. It was a miscommunication, though, because that's not the requirement. Customers aren't and won't ever be deciding on their own output format. It's all for our own app/website.

OK. I think it's still a demonstration of the fact that some data structures are good for some kinds of computation, but bad for others.

For example, if you stored it *only* in something very much like the user input, answering questions like "what stores are open at 5pm" can become much harder.

That is, you can not really separate "how should the data be stored" from "what do I want to do with the data"

I still only partially agree.

If you have to answer questions like what stores are open at 5pm, you have to store the data in some kind of structured way (ie, not allow arbitrary user input which you somehow interpret). That to me is just a data validation problem.

I still believe if you are storing structured data for info like this -- whether using a bit type, a postgres array, a bindery table, or other -- it's not really that important to think about how it's going to be used, because transformations and queries are so easy. If it's a massive dataset, and you need performance on some massive queries or something like that -- then sure. But in normal cases I'd rather use a simple structure that works, and let my application code take care of its own needs, rather than let some particular application impose structure on my db.

Random db musing, use a string of hex similar to the file permissions in UNIX?

Postgresql timestamp functions are awesome and it's probably a mistake to not use them when dealing with dates and times.

tsrange (or it's timezone-supporting tstzrange) are probably ideal here, although I've used both a "bitmask" type thing (generate series for 5 minute intervals with a bool column for open/closed) and a simple pair of columns (open_time timezone, duration interval)

You can store a time relative to the start of the week with a resolution of 1 second in 20 bits. You can store Unix Time in 64 bits. Probably makes too many bytes to store in a DB, not sure. Converting to time zone, year, day of the week, time of day is well supported in a lot of environments.

this returns false.
It doesn't take a lot of imagination to see how this will go sideways and make updating, inserting, and querying very difficult.

My idea could just well be json.

Absolutely agree.

thanks, i'll look into them.

I had to do something similar for a hunting guide scheduler a while back
I set up a 3 column db that had day, open , close as the three columns
for the day I used a number 0=sun, 1=mon, etc
and for hours I used 0-23

so for this the table would look like
M closed
T-F 9-12, 1-6
S 10-2
U 10-3

2,9,12
2,13,18
3,9,12
3,13,18
...
6,10,14
0,10,15

then for if you have a date time you can do a

select * from schedule where day = EXTRACT(DOW FROM TIMESTAMP CURRENT_TIMESTAMP); and open>EXTRACT(hour FROM TIMESTAMP CURRENT_TIMESTAMP); and close < EXTRACT(hour FROM TIMESTAMP CURRENT_TIMESTAMP);

if it returns something it's open right now

I just cracked 20 KLOC on my current project. I don't know how I'm supposed to feel about this.

Ideas for projects that one could work on in order to show employers when applying for SD jobs?
I'm currently on my second year as a CS student, and starting to look for jobs. I feel like I'm proficient enough to land some kind of entry level programming gig, but right now I really don't have any code that I could show off that would improve my chances of landing said gig.
I'm looking for ideas on generic projects to work on, preferably something that's relatively small in size ie won't take a huge amount of time/work to finish but still shows a good understanding and capability of programming if done elegantly.

I'm hoping you guys can help me get some good ideas. I'm thinking something that is responsive with the user and fetches some data based on user input. I'm most familiar with object-oriented programming (most code written in Java in the past), and something that would allow me to show capability to use some OOP concepts efficiently would be a plus

This might be too hard of a question to answer without knowing my capabilities etc, but any vague ideas are appreciated thanks guys

Todo list with user authentication

Multi-room chat server/client with authentication

Funny that you should mention it, since I got asked this exact question (...How would you implement a to-do list...) in a job interview a few weeks ago.
Seems like a great idea, I'll definitely consider it thanks

This seems a bit harder do to, I'm not sure how you would allow users to be connected together and receive each others messages in real-time. Seems like something I might want to look into, any ideas on where to start?

Thanks for the fast responses and decent ideas so far guys

I'd recommend you just work on something that interests you and may actually see some real-world use, choose the technology in a way that benefits your resume. Start out with something small and gradually increase complexity, you'll probably stumble into more project ideas naturally based on user feedback.

Can be anything really. The first few projects i wrote were tiny tools (<10h) for PC games, some of these are still in active use by the community 15 years later

Websockets/socketio for chat.

This probably won't happen unless you make a real "program". Most of web development is pulling together pieces/writing logic around them, as opposed to creating an OOP system that has top level classes that inherit from different prototypes/other classes etc. Just having general knowledge of how it works is nice but probably not critical.

You should make something that solves a problem for you, or creates something that you want to see in the world. When it's something that you want, the features that you should build will be obvious instead of obscure. Faults with it will be apparent, as will potential fixes and improvements. You'll actually want to work on it instead of just doing it because you feel like you have to.

I've been programming 25 years and I always have at least 2 or 3 side projects going. I spent all of the last 3 days working on one of them.

That advice to build something that solves a problem for you advice gets spouted everywhere. I've only rarely had something occur to me that would fit in there. I can't be the only one that doesn't have a constant stream of these ideas.

I dunno what to say. I have more ideas for stuff I want computers to do for me than I have time. That was my motivation for getting into computer programming in the first place - I wanted to have computers do stuff for me.

What motivated you to get into programming?

My motivation would be the same as Rusty's and I was under the assumption that's pretty common so I'd be interested to hear your thoughts. Thanks!

Thanks guys,

And working on something that interests you/solves a problem for you is a great idea as well. I do have a few ideas that I would like to work on, but I wanted to ask around for ideas to see if some of you had ideas that might be more practical, easier to create etc.
I really want to get something small done relatively quickly so that I at least have something to show off when applying for jobs. then I can tell them I'm working on some other stuff as well and will have more code to show off soon. The 2-3 ideas that I have that are of personal interest to me might be a bit complex to make, and I like to let these ideas linger in my mind for a bit anyway, as well as having more time to work on them when I do get started

Anyway thanks for great answers guys! I think I'll get started on the To-do list, as I have a much clearer idea of how that might be done, and possibly move onto the chat idea later, at least checking out the mentioned API's and go from there. As well as maybe working on some of my own ideas as well

Writing a chat program is fun. I wrote one very early in my programming career. I was using a scripting language and to make a very fully featured program, I actually had my client just send the code it wanted the recipient(s) to run on their end. This obviously had huge security holes and part of the fun was finding ways to make funny stuff happen on your opponent's friend's screens, and finding ways to stop it from happening.

That program lived on for many years and eventually I made it support several existing chat protocols, like Yahoo IM and MSN's IM. It later became the core of a system I used for RPC invocation - and that I still use today.

My point is that your projects don't have to be rote busywork to prove a point. They have many uses
* the improve your skills
* they give you something to show
* you will learn lessons from them
* you may reuse them, or the ideas from them, over and over again

server program that accepts connections and creates threads for new users, and sends all messages received to every listener for the room (have you looked into multi-threaded apps or design patterns at all yet?)

client program that connects to the server and displays messages received from the server

The MSN protocol was interesting in that when you wanted to have a private chat with people, the server would negotiate one of you as the "master" and your client would connect to a specified port on their client. This required that you could route to a range of ports on their machine, which was more common in the early days of the internet than today.

It had the advantage of offloading chat messages from their server, which only had to manage the negotiation phase, along with keeping track of each user's status (offline, here, away, taking a dump, etc)