tech Programmers Thread: King Python, C#, Javascript, Java

[ccfan007]

Completed my associated in Computer Science a few years ago and finishing up my bachelors this year. I've done a lot of different languages and really enjoyed playing around with python and java but php is my love 

Edited May 19, 2022 by ccfan007

[Pikachoo]

@Bloo@Vrx. i know you guys actually work in software development/ it so maybe you can give me advice

 

so basically, the repository that I'm responsible for at work is basically a bunch of micro services thrown into the same repo because there was no where else to put it.

 

I'm debating if it would be worth it to create these into micro services for each function.

 

Pros

- more independent = less likely that changes need to be rolled back for problems that occurred in other parts of the repo (which happens and it gets messy where we need to cherry pick some stuff into a branch and leave other things out just to make sure the changes we want are included and those we dont excluded)
- won't break in production because of issues in other parts of the running code (related to first point)

- more agile in the sense that each micro service can have a release much more frequently, since its not depending on everything else and it's much smaller. (right now, we have scheduled monthly releases for the whole repo.)

 

 basically, micro services = stability and flexibility.

 

Cons:

- our repo shares a common library. basically, each micro service would need to have dependencies for this library. in other words, we would need to configure the same library 5 times instead of a one and done.

- if every micro service needs changes, that's 4 extra production releases to handle instead of one.

- more overhead in terms of docker and blablabla..

 

mono repo = less overhead

 

what do you all think? My boss is basically letting me take the reins on this repo and I don't want to do changes just for the sake of doing them

[Bloo]

32 minutes ago, Pikachoo said:

@Bloo@Vrx. i know you guys actually work in software development/ it so maybe you can give me advice

 

so basically, the repository that I'm responsible for at work is basically a bunch of micro services thrown into the same repo because there was no where else to put it.

 

I'm debating if it would be worth it to create these into micro services for each function.

 

Pros

- more independent = less likely that changes need to be rolled back for problems that occurred in other parts of the repo (which happens and it gets messy where we need to cherry pick some stuff into a branch and leave other things out just to make sure the changes we want are included and those we dont excluded)
- won't break in production because of issues in other parts of the running code (related to first point)

- more agile in the sense that each micro service can have a release much more frequently, since its not depending on everything else and it's much smaller. (right now, we have scheduled monthly releases for the whole repo.)

 

 basically, micro services = stability and flexibility.

 

Cons:

- our repo shares a common library. basically, each micro service would need to have dependencies for this library. in other words, we would need to configure the same library 5 times instead of a one and done.

- if every micro service needs changes, that's 4 extra production releases to handle instead of one.

- more overhead in terms of docker and blablabla..

 

mono repo = less overhead

 

what do you all think? My boss is basically letting me take the reins on this repo and I don't want to do changes just for the sake of doing them

Well, I’m a computer scientist. I’m not a software engineer. I’m comfortable writing code but I don’t maintain large software projects. So I don’t feel too comfortable providing much input. I would just suggest speaking with other members in your organization about what makes the most sense. Your idea sounds like it would take time and while it might be intuitive, it might cause some unaccounted for issues. So maybe just chat with others at your organization to see if they vouch for your idea. 

[Vrx.]

@Pikachoo This is a prime candidate for creating utilities/libraries to house central logic, and also creating some sort of method of ensuring that your repository is utilizing the same method(s) with the same logic. The most important questions to ask when doing something like this is the following:

 

1. Builds - How will centralizing all of these functions impact builds? What are the pros and cons for your logic to be build out separately? Will centralizing logic be appropriate across all of the components that are using it, including if you update logic that may have impacts on another (ie maybe one requires a different version than the other) 

 

2. CI/CD - How do you intend to propagate the changes? What sort of git structure are you using? It’s important to note that cloud and serverless are different from standard apps or libs. 
 

3. Maintenance - This one is a no brainer. It is so much easier to retain one utility library than it is to make the same changes in multiple places. The bulk of this is actually the initial work of centralizing it, but it’s a lot easier in the long term. 
 

4. Downtime/Testing/Impact - What effects will this have on the items it is impacting? Will there need to be downtime? 
 

I’d love to hear more about your potential solution as well as some of the frameworks you use. I’ve actually done something exactly like this before using Docker/Terraform and Jenkins so that’s why I’d love to see if I could help 

[Vrx.]

Also -

 

My current role deals with Python, React, Docker/Jenkins/Terraform, Containerized cloud-based functionality, ROS and other IOT relays, as well as automata. If you have any questions or want to chat about that feel free to! 

[Pikachoo]

9 minutes ago, Vrx. said:

@Pikachoo This is a prime candidate for creating utilities/libraries to house central logic, and also creating some sort of method of ensuring that your repository is utilizing the same method(s) with the same logic. The most important questions to ask when doing something like this is the following:

 

1. Builds - How will centralizing all of these functions impact builds? What are the pros and cons for your logic to be build out separately? Will centralizing logic be appropriate across all of the components that are using it, including if you update logic that may have impacts on another (ie maybe one requires a different version than the other) 

 

2. CI/CD - How do you intend to propagate the changes? What sort of git structure are you using? It’s important to note that cloud and serverless are different from standard apps or libs. 
 

3. Maintenance - This one is a no brainer. It is so much easier to retain one utility library than it is to make the same changes in multiple places. The bulk of this is actually the initial work of centralizing it, but it’s a lot easier in the long term. 
 

4. Downtime/Testing/Impact - What effects will this have on the items it is impacting? Will there need to be downtime? 
 

I’d love to hear more about your potential solution as well as some of the frameworks you use. I’ve actually done something exactly like this before using Docker/Terraform and Jenkins so that’s why I’d love to see if I could help 

we use an in-house platform similar to Docker and Kubernetes. We use Jenkins for all our automated testing and deployment. My other concern is, right now, I'm the only one working on this repo. but the moment a few more developers start working on this repo, It can get messy. whose changes need to be released, whose needs to be cherry picked..all working different component inside the one repo.. so maybe not microservices, but leaning towards one repo per component. they can definitely be standalone.. its just the library overhead that concerns me

Edited May 27, 2022 by Pikachoo

[Vrx.]

49 minutes ago, Pikachoo said:

we use an in-house platform similar to Docker and Kubernetes. We use Jenkins for all our automated testing and deployment. My other concern is, right now, I'm the only one working on this repo. but the moment a few more developers start working on this repo, It can get messy. whose changes need to be released, whose needs to be cherry picked..all working different component inside the one repo.. so maybe not microservices, but leaning towards one repo per component. they can definitely be standalone.. its just the library overhead that concerns me

That means that you need to perform the cleanup in such a way that you are able to house the main functionality in one centralized place where they don’t need to worry about other repos. You can pull remote states of the containerized environment and access different resources during deployment so I wouldn’t worry too much about others. In the end they’ll thank you for streamlining this process. Also, this is a great time to learn about the real inner workings of your teams projects! 

[Pikachoo]

18 minutes ago, Vrx. said:

That means that you need to perform the cleanup in such a way that you are able to house the main functionality in one centralized place where they don’t need to worry about other repos. You can pull remote states of the containerized environment and access different resources during deployment so I wouldn’t worry too much about others. In the end they’ll thank you for streamlining this process. Also, this is a great time to learn about the real inner workings of your teams projects! 

what do you mean by 'pull remote states of the containerized enviroment and access different resources during deployment'? ive been a pure developer up until now, so devops is a new field for me. i know the basics of docker and such but not the specifics

 

i was talking more so about release branches on git. lets say qa finds something wrong in regression testing, we either implement a fix or if theres no time, back out of the release. but if there's other changes (related to separate functionality) that needs to go in, it gets messy with cherry-picking.. but if it was a single repo per functionality, it'd be easier to manage, right?

[Vrx.]

5 hours ago, Pikachoo said:

what do you mean by 'pull remote states of the containerized enviroment and access different resources during deployment'? ive been a pure developer up until now, so devops is a new field for me. i know the basics of docker and such but not the specifics

 

i was talking more so about release branches on git. lets say qa finds something wrong in regression testing, we either implement a fix or if theres no time, back out of the release. but if there's other changes (related to separate functionality) that needs to go in, it gets messy with cherry-picking.. but if it was a single repo per functionality, it'd be easier to manage, right?

Remote state is basically non-local files that you’re able to access while you’re in a containerized state. Additionally when you deploy your container you’re able to access different sections of your repos while you’re in the container. Remote state just refers to your current containerized state. 

[noahfence]

Currently going through this lovely course https://www.udemy.com/course/react-the-complete-guide-incl-redux/ and not like I needed another reminder that I'm dumb....but this is so overwhelming. I'm in the chapter where he is creating a validation form for email and password, and it already has a billion lines of code and it's not readable at all. I know React has benefits, and it is all the rage...but how do you all learn this... 

[Pikachoo]

On 5/27/2022 at 7:30 PM, Vrx. said:

Remote state is basically non-local files that you’re able to access while you’re in a containerized state. Additionally when you deploy your container you’re able to access different sections of your repos while you’re in the container. Remote state just refers to your current containerized state. 

ah, ok thanks! I wonder if this (thinking about the design of the system and its scalability) would be a good talking point in a potential job interview in the future? or do interviews just care about algorithms

[Vrx.]

19 hours ago, Pikachoo said:

ah, ok thanks! I wonder if this (thinking about the design of the system and its scalability) would be a good talking point in a potential job interview in the future? or do interviews just care about algorithms

After college nobody is going to ask you how you’re using the Fisher sorting algorithm or Dijkstra’s algorithm. That’s pretty much questions for sweat shops like Amazon. If you actually interview at companies that aren’t really the big tech giants, you’ll notice they care more for your experiences. I’d say being in the industry I’ve strayed away from companies that ask you to recite textbook materials because it means that they generally have high turnover and are strict with how much code you can access. Plus after 5 years you’ll not really get asked those questions. Of course, if you’re going into optimization and sectors that require these algorithms you should be aware of it. 
 

Just as an FYI - an algorithm is your approach to solving a problem. It doesn’t have to strictly apply to code. Coding algorithms are not the same as overall algorithms and heuristics. 

[Vrx.]

On 5/29/2022 at 6:31 AM, noahfence said:

Currently going through this lovely course https://www.udemy.com/course/react-the-complete-guide-incl-redux/ and not like I needed another reminder that I'm dumb....but this is so overwhelming. I'm in the chapter where he is creating a validation form for email and password, and it already has a billion lines of code and it's not readable at all. I know React has benefits, and it is all the rage...but how do you all learn this... 

react’s big benefit is with use effects. I’d actually start with vanilla javascript so you can understand the language (single threaded, basic syntax, async/await, and how the schedulers work in the language)  

[Vrx.]

@noahfenceAlso please keep in mind that react has a lot of what we call boilerplate code. This is basically things that make it more verbose that are done to ensure that you do not need a more intimate knowledge of programming. It is done a lot more in higher level languages as many of these variables or functions have tons of wrappers internally to make it seem like one line of code. It’s a trade off. If you find yourself struggling, I’d really recommend you start with Vanilla Javascript or Node.js, and then work towards the front end frameworks. It may seem tedious, but it does help you understand the fundamentals of how web services and web apps work prior to jumping into building one

[noahfence]

3 hours ago, Vrx. said:

@noahfenceAlso please keep in mind that react has a lot of what we call boilerplate code. This is basically things that make it more verbose that are done to ensure that you do not need a more intimate knowledge of programming. It is done a lot more in higher level languages as many of these variables or functions have tons of wrappers internally to make it seem like one line of code. It’s a trade off. If you find yourself struggling, I’d really recommend you start with Vanilla Javascript or Node.js, and then work towards the front end frameworks. It may seem tedious, but it does help you understand the fundamentals of how web services and web apps work prior to jumping into building one

thank you, sweetheart 

I had finished a JavaScript course prior to starting the React one and done few projects for myself. But I still find React quite difficult. Especially when you need to declare a Use Effect which returns a variable and a function, but you can't use the function directly, you need to declare another function that in turn calls the function of the Use Effect. And only then you have to pass it down as a prop to the actual component that does something with it. But oh no when there are too many Use Effects you better start using a Context hook which declares a declaration of declaration of a function which calls another function which does something, then you have to wrap every component with this context component. and then you think well okay then this context hottie is better because it allows you to use it everywhere without creating prop chains and then you learn there are multiple caveats and overall you better stick with Use Effects.

 

Sorry for rambling  I know that it all comes with experience and creating your own projects. I just finally want to choose one programming language / framework and master it to apply for a better job

[Vrx.]

1 hour ago, noahfence said:

thank you, sweetheart 

I had finished a JavaScript course prior to starting the React one and done few projects for myself. But I still find React quite difficult. Especially when you need to declare a Use Effect which returns a variable and a function, but you can't use the function directly, you need to declare another function that in turn calls the function of the Use Effect. And only then you have to pass it down as a prop to the actual component that does something with it. But oh no when there are too many Use Effects you better start using a Context hook which declares a declaration of declaration of a function which calls another function which does something, then you have to wrap every component with this context component. and then you think well okay then this context hottie is better because it allows you to use it everywhere without creating prop chains and then you learn there are multiple caveats and overall you better stick with Use Effects.

 

Sorry for rambling  I know that it all comes with experience and creating your own projects. I just finally want to choose one programming language / framework and master it to apply for a better job

Of course! If you need help please reach out. Funny enough, you can actually avoid stuff like functors with use effects by just storing state variables (like page saving/saved) which can be triggered by other use effects and propagate across contexts! React can be really cool and you can build beautiful apps if you take the time to get those foundations right. 
 

may I ask what you’re looking for in your career? 

[Pikachoo]

13 hours ago, Vrx. said:

After college nobody is going to ask you how you’re using the Fisher sorting algorithm or Dijkstra’s algorithm. That’s pretty much questions for sweat shops like Amazon. If you actually interview at companies that aren’t really the big tech giants, you’ll notice they care more for your experiences. I’d say being in the industry I’ve strayed away from companies that ask you to recite textbook materials because it means that they generally have high turnover and are strict with how much code you can access. Plus after 5 years you’ll not really get asked those questions. Of course, if you’re going into optimization and sectors that require these algorithms you should be aware of it. 
 

Just as an FYI - an algorithm is your approach to solving a problem. It doesn’t have to strictly apply to code. Coding algorithms are not the same as overall algorithms and heuristics. 

I was thinking of applying to Amazon I was messaged by an Amazon recruiter on Linkedin.. they pay the big bucks lol.. what have you heard of Amazon? is it really high turnover?

[Price of Fame]

Amazon has terrible work/life balance and loves to PIP people out (or even hire to fire to keep good employees) 

i don’t know anyone who’s come out of Amazon that wasn’t happy to leave 

[noahfence]

10 hours ago, Vrx. said:

Of course! If you need help please reach out. Funny enough, you can actually avoid stuff like functors with use effects by just storing state variables (like page saving/saved) which can be triggered by other use effects and propagate across contexts! React can be really cool and you can build beautiful apps if you take the time to get those foundations right. 
 

may I ask what you’re looking for in your career? 

Sounds really exciting 

As for me... On one hand I love Frontend because it's something you can see instantly, you can touch it, interact with it, plus I love Adobe Illustrator, After Effects, and Blender, so it's amazing when I can create banners and then use it for my project. But when I start diving deeper into Frontend it looks like a whole intricate universe which I can only learn if I have enough time and energy. But with my current job it's almost impossible. On the other hand I love data, so Backend seems pretty cool as well, I've had little experience with PHP, and I enjoyed it. When I was going through a Python course there was a section on Flask, and I thought maybe I should stick to it, but ended up downloading the React one 

Overall, I just finally want to choose one field which brings me joy and is in demand to earn money 

[Price of Fame]

54 minutes ago, noahfence said:

Sounds really exciting 

As for me... On one hand I love Frontend because it's something you can see instantly, you can touch it, interact with it, plus I love Adobe Illustrator, After Effects, and Blender, so it's amazing when I can create banners and then use it for my project. But when I start diving deeper into Frontend it looks like a whole intricate universe which I can only learn if I have enough time and energy. But with my current job it's almost impossible. On the other hand I love data, so Backend seems pretty cool as well, I've had little experience with PHP, and I enjoyed it. When I was going through a Python course there was a section on Flask, and I thought maybe I should stick to it, but ended up downloading the React one 

Overall, I just finally want to choose one field which brings me joy and is in demand to earn money 

Full stack is the way to go! 

[noahfence]

Me, and my girlsies @Price of Fame @Vrx. fullstacking  

[Vrx.]

6 hours ago, Pikachoo said:

I was thinking of applying to Amazon I was messaged by an Amazon recruiter on Linkedin.. they pay the big bucks lol.. what have you heard of Amazon? is it really high turnover?

Terrible, especially in terms of work/life balance. You will probably be drained overtime (standard engineers work 60-80 hrs a week) and vacation time is actually really hard to take. Also, their interviews are now like follows:

 

1. A recruiter reaches out to you, and you submit your resume. 

2. You have to take the Amazon exam which is sort of like a Hackerrank assessment. This is before even speaking to anyone "to not waste time"

3. If you do OK, you go through the in person phone/virtual interview with some more questions. That's it.

 

It's super impersonal and basically serves to function and see if you're able to just memorize/recite algorithms and have little brain power. People who work for Amazon that I've worked with are surprisingly not actually good at programming - they're excellent at memorizing and pattern recognition and using the same solutions over and over again, but they aren't as proficient with advanced problem solving since Amazon likes to keep the status quo. Overall wouldn't recommend unless you just want Big Tech on your resume. If so, just legit study Dijkstra's algorithm and string searches as it's their favorite optimization problem.

 

2 hours ago, noahfence said:

Sounds really exciting 

As for me... On one hand I love Frontend because it's something you can see instantly, you can touch it, interact with it, plus I love Adobe Illustrator, After Effects, and Blender, so it's amazing when I can create banners and then use it for my project. But when I start diving deeper into Frontend it looks like a whole intricate universe which I can only learn if I have enough time and energy. But with my current job it's almost impossible. On the other hand I love data, so Backend seems pretty cool as well, I've had little experience with PHP, and I enjoyed it. When I was going through a Python course there was a section on Flask, and I thought maybe I should stick to it, but ended up downloading the React one 

Overall, I just finally want to choose one field which brings me joy and is in demand to earn money 

Why not do fullstack? It's the ideal thing for you. You build it from the ground up. It makes you way better as a developer and even someone who is a computer scientist in general. 

[Pikachoo]

1 hour ago, Vrx. said:

Terrible, especially in terms of work/life balance. You will probably be drained overtime (standard engineers work 60-80 hrs a week) and vacation time is actually really hard to take. Also, their interviews are now like follows:

 

1. A recruiter reaches out to you, and you submit your resume. 

2. You have to take the Amazon exam which is sort of like a Hackerrank assessment. This is before even speaking to anyone "to not waste time"

3. If you do OK, you go through the in person phone/virtual interview with some more questions. That's it.

 

It's super impersonal and basically serves to function and see if you're able to just memorize/recite algorithms and have little brain power. People who work for Amazon that I've worked with are surprisingly not actually good at programming - they're excellent at memorizing and pattern recognition and using the same solutions over and over again, but they aren't as proficient with advanced problem solving since Amazon likes to keep the status quo. Overall wouldn't recommend unless you just want Big Tech on your resume. If so, just legit study Dijkstra's algorithm and string searches as it's their favorite optimization problem.

 

Why not do fullstack? It's the ideal thing for you. You build it from the ground up. It makes you way better as a developer and even someone who is a computer scientist in general. 

I had actually bought 'Cracking The Coding Interview' by Gayle Laakmann McDowell, which is basically an interview prep for big tech companies. You're right, the book is mostly "remember these sorting algorithms and data structures"

 

any big tech companies that you've heard good things about? Microsoft? Apple? Google?

[Hot Volcano]

What is the best way to retrieve emails and their content (body and attachments) and store them into a Oracle table in a database?

[gugunikko]

Any tips for studying Java programming ?