Я тут уже весь форум своими темами завалил, простите.
Захотелось высказаться по теме сабжа. Я в самом ИИ ничего не понимаю. Но люблю им восхищаться и даже немножко профинансировал микрософт покупкой подписки на копилот, коим пользуюсь.
Недавно поговорил с ChatGPT. Кстати рекомендую, пока бесплатно. Отрыв башки, конечно. Я его попросил мне написать функцию генератора паролей на JS — он написал, рабочую. Но через Math.random. Я его попросил написать через crypto, он написал. Но через %, что даёт некоторый биас. Я ему указал на это, он написал через float. В целом можно считать приемлемо, биас там чисто теоретический остался. Хотя я сделал по-другому. Но к коду у меня претензий нет. Если бы это написал коллега, я бы на код ревью не придирался.
И в итоге я для себя вывод сделал. Если этого бота оформить в виде полноценного продукта и добавить туда хороший голосовой ввод, то я смогу с его помощью генерировать приемлемый код с очень неплохой скоростью, когда поднаторею в общении с ним.
Но с другой стороны дай его новичку, и он остановится на первом варианте. А первый вариант совсем плохонький, да и второй не очень хорош.
То бишь в итоге получается, что ИИ увеличивает скорость написания кода и качество кода. Но при этом он не делает из плохого программиста — хорошего.
В целом я, конечно, как и 99% остальных считаю себя хорошим программистом но при этом мне кажется, что есть немаленькая вероятность, что хорошие программисты, вооружившись этими инструментами просто сделают ненужными плохих программистов.
Под плохими я не обязательно понимаю глупых, просто неопытных.
Вот в чём я точно сомневаюсь, что эти инструменты вытеснят программистов в принципе и менеджеры смогут надиктовывать программы сами. Имхо, этого пока не случится. А когда случится, то и менеджеры будут не нужны.
Здравствуйте, vsb, Вы писали:
vsb>Недавно поговорил с ChatGPT. Кстати рекомендую, пока бесплатно. Отрыв башки, конечно. Я его попросил мне написать функцию генератора паролей на JS — он написал, рабочую. Но через Math.random. Я его попросил написать через crypto, он написал. Но через %, что даёт некоторый биас. Я ему указал на это, он написал через float. В целом можно считать приемлемо, биас там чисто теоретический остался. Хотя я сделал по-другому. Но к коду у меня претензий нет. Если бы это написал коллега, я бы на код ревью не придирался.
, он ничего разумного не смог ответить, одни оправдания.
Он ничегошеньки не знает про котят с очень длинным телом. В общем как в анекдоте про мужиков и японскую бензопилу
С нынешним ОТУПЕВШИМ поколением макак-погромиздов мы не то, что ИИ, мы простую ГУЙню потеряем! Я не голословен — мы УЖЕ почти потеряли WPF: несмотря на всю декларативность, так и остался windows-only.
Ну и потом, не будьте подобны бабкам у подъезда — научитесь уже отличать ИИ от банальных распознавателей картинок или "обучающейся недосети".
Не совсем про программирование но попробовал с ним поговорить. Вот диалог, может кому интересно будет.
> Which CNI for my Kubernetes cluster should I choose? I'm alternating between Calico and Cilium.
There are many different options when it comes to choosing a CNI (Container Network Interface) for your Kubernetes cluster, and the choice ultimately depends on your specific needs and requirements. Both Calico and Cilium are popular options, and each has its own strengths and weaknesses.
Calico is a robust, high-performance CNI that offers a variety of features, such as network policy enforcement, network visibility and troubleshooting, and integration with cloud native networking frameworks. It is also relatively easy to set up and configure, making it a good choice for many users.
Cilium, on the other hand, offers a unique approach to networking that is based on the Linux kernel's BPF (Berkeley Packet Filter) technology. This allows Cilium to provide fine-grained, scalable network security policies and visibility, as well as high performance and low overhead. Cilium is also a good choice for users who require advanced networking features, such as load balancing and service discovery.
In the end, the best CNI for your Kubernetes cluster will depend on your specific requirements and use cases. It's a good idea to try out both Calico and Cilium, as well as other CNIs, and see which one works best for your needs.
> Are there any good alternatives to ingress-nginx?
Yes, there are several alternatives to ingress-nginx that you can use for managing external access to your Kubernetes services. Some popular options include:
Contour: Contour is an Envoy-based ingress controller that provides a number of features, such as dynamic reconfiguration, support for multiple protocols, and fine-grained traffic control.
Traefik: Traefik is a widely-used ingress controller that offers features such as automatic service discovery, support for multiple protocols, and load balancing. It is also easy to set up and configure, making it a good choice for many users.
HAProxy: HAProxy is a popular open-source load balancer and reverse proxy that can be used as an ingress controller for Kubernetes. It offers high performance, reliability, and a wide range of features, including support for multiple protocols and advanced load balancing algorithms.
In addition to these options, there are many other ingress controllers available, each with its own unique features and capabilities. It's a good idea to evaluate your specific requirements and use cases, and choose an ingress controller that is best suited to your needs.
> Which of those ingress controllers support proxy v2 protocol to receive client IP address from the load balancer?
Most ingress controllers support the proxy v2 protocol, which allows the ingress controller to receive the client IP address from the load balancer. This includes popular options such as Contour, Traefik, and HAProxy.
To use the proxy v2 protocol with these ingress controllers, you will need to configure the load balancer to use the PROXY protocol, and then configure the ingress controller to receive the client IP address from the load balancer. This is typically done by setting the real_ip_header and real_ip_recursive options in the ingress controller's configuration file.
For example, to use the proxy v2 protocol with Contour, you would add the following lines to the ingress controller's configuration file:
envoy_stats_sinks:
real_ip:
real_ip_header: x-forwarded-for
real_ip_recursive: on
You can then verify that the ingress controller is receiving the client IP address by checking the logs or using the ingress controller's built-in debugging tools.
It's important to note that the specific configuration steps may vary depending on the ingress controller you are using, as well as the load balancer and other factors. It's a good idea to consult the documentation for your specific ingress controller and load balancer to ensure that you are configuring everything correctly.
Короче собеседование он провалил. Болтает много, а толку мало.
> Can you tell me the result of the following JavaScript expression:
> ["192", "168", "0", "1"].map(parseInt)
The result of calling the map method on the array ["192", "168", "0", "1"] with the parseInt function as the callback will be an array of numbers. The first element in the resulting array will be 192, the second element will be 168, the third element will be 0, and the fourth element will be 1.
However, calling parseInt in this way can lead to unexpected results because the map method passes three arguments to the callback function: the current element, the current index, and the array being mapped. In this case, the first argument passed to `parseInt will be the string "192", the second argument will be the number 0 (the index of the first element in the array), and the third argument will be the original array.
When parseInt is called with a string as the first argument and a number as the second argument, it will interpret the string as a number in the specified radix (base). In this case, the radix will be 0, which tells parseInt to interpret the string based on the leading characters of the string. If the string begins with "0x", the number will be interpreted as a hexadecimal (base 16) number. If the string begins with "0", the number will be interpreted as an octal (base 8) number. If the string begins with any other character, the number will be interpreted as a decimal (base 10) number.
Since the string "192" does not begin with "0x" or "0", parseInt will interpret it as a decimal number and will return the number 192. However, the string "168" does begin with "0", so parseInt will interpret it as an octal number. In octal, the number "168" is not a valid number and parseInt will return NaN (not a number) for this element. The same thing will happen for the string "0", which will be interpreted as an octal number and will also return NaN. Finally, the string "1" will be interpreted as a decimal number and will return the number 1.
So, the resulting array from calling map with parseInt as the callback will be [192, NaN, NaN, 1]. This is not the expected result and can be confusing, so it's generally better to use a different callback function when calling map with parseInt or to use a different method altogether.
One way to get the expected result (an array of numbers corresponding to the original strings) is to use the Number function as the callback function for map. The Number function will simply convert its argument to a number, so it will produce the expected result without the need for additional arguments. For example, you could use the following code to produce the expected result:
["192", "168", "0", "1"].map(Number)
This would return the array [192, 168, 0, 1], which is the expected result.
> Why do you claim that string "168" begins with "0"? If begins with "1".
You are correct, the string "168" does not begin with "0". My mistake. When parseInt is called with a string as the first argument and a number as the second argument, it will interpret the string as a number in the specified radix (base). In this case, the radix will be 0, which tells parseInt to interpret the string based on the leading characters of the string. If the string begins with "0x", the number will be interpreted as a hexadecimal (base 16) number. If the string begins with any other character, the number will be interpreted as a decimal (base 10) number.
Since the string "168" does not begin with "0x" or "0", parseInt will interpret it as a decimal number and will return the number 168. The same thing will happen for the string "0", which will also be interpreted as a decimal number and will return the number 0. The string "1" will also be interpreted as a decimal number and will return the number 1.
So, the resulting array from calling map with parseInt as the callback will be [192, 168, 0, 1], which is the expected result.
As I mentioned earlier, it's generally better to use a different callback function when calling map with parseInt or to use a different method altogether. One way to get the expected result (an array of numbers corresponding to the original strings) is to use the Number function as the callback function for map. The Number function will simply convert its argument to a number, so it will produce the expected result without the need for additional arguments. For example, you could use the following code to produce the expected result:
Copy code
["192", "168", "0", "1"].map(Number)
This would return the array [192, 168, 0, 1], which is the expected result.
> Actually if you would run code I asked in my question, you would find out that it returns
> [192, NaN, 0, 1]
> Can you explain this result?
Yes, you are correct. The result of calling the map method on the array ["192", "168", "0", "1"] with the parseInt function as the callback will be an array with the following elements: 192, NaN, 0, and 1.
As I mentioned in my previous response, calling parseInt in this way can lead to unexpected results because the map method passes three arguments to the callback function: the current element, the current index, and the array being mapped. In this case, the first argument passed to `parseInt will be the string "192", the second argument will be the number 0 (the index of the first element in the array), and the third argument will be the original array.
When parseInt is called with a string as the first argument and a number as the second argument, it will interpret the string as a number in the specified radix (base). In this case, the radix will be 0, which tells parseInt to interpret the string based on the leading characters of the string. If the string begins with "0x", the number will be interpreted as a hexadecimal (base 16) number. If the string begins with "0", the number will be interpreted as an octal (base 8) number. If the string begins with any other character, the number will be interpreted as a decimal (base 10) number.
Since the string "192" does not begin with "0x" or "0", parseInt will interpret it as a decimal number and will return the number 192. However, the string "168" does not begin with "0x" or "0" either, so parseInt will also interpret it as a decimal number. In decimal, the number "168" is a valid number and parseInt will return the number 168 for this element.
The string "0" begins with "0", so parseInt will interpret it as an octal number. In octal, the number "0" is a valid number and parseInt will return the number 0 for this element. Finally, the string "1" will be interpreted as a decimal number and will return the number 1.
So, the resulting array from calling map with parseInt as the callback will be [192, 168, 0, 1]. This is not the expected result and can be confusing, so it's generally better to use a different callback function when calling map with parseInt or to use a different method altogether.
One way to get the expected result (an array of numbers corresponding to the original strings) is to use the Number function as the callback function for map. The Number function will simply convert its argument to a number, so it will produce the expected result without the need for additional arguments. For example, you could use the following code to produce the expected result:
["192", "168", "0", "1"].map(Number)
This would return the array [192, 168, 0, 1], which is the expected result.
Здравствуйте, vsb, Вы писали:
vsb>В целом я, конечно, как и 99% остальных считаю себя хорошим программистом но при этом мне кажется, что есть немаленькая вероятность, что хорошие программисты, вооружившись этими инструментами просто сделают ненужными плохих программистов.
А не получится, что хорошие программисты, вооружившись этими инструментами просто сделают себя плохими программистами ?
Здравствуйте, vsb, Вы писали:
vsb>Вот в чём я точно сомневаюсь, что эти инструменты вытеснят программистов в принципе и менеджеры смогут надиктовывать программы сами. Имхо, этого пока не случится. А когда случится, то и менеджеры будут не нужны.
Насколько я понимаю, мы пока получили базу ответов со SO уже не где-то там в гугле, а у себя в IDE. Если раньше приходилось их искать,читать темы и анализировать, то сейчас просто анализировать. Делает ли SO программистов умнее или тупее?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А не получится, что хорошие программисты, вооружившись этими инструментами просто сделают себя плохими программистами ?
Себя-то не сделают, а вот получится ли учить управлять этим ИИ у тех, кто не прогал руками и не знает, что такое ИИ?
Здравствуйте, vsb, Вы писали:
vsb>В целом я, конечно, как и 99% остальных считаю себя хорошим программистом но при этом мне кажется, что есть немаленькая вероятность, что хорошие программисты, вооружившись этими инструментами просто сделают ненужными плохих программистов.
Не надо делить на хороших и плохие. Лучше по степени квалификации. Тогда, вдруг, окажется, что высококвалифицированым, вооруженным ИИ, будет гораздо легче вовлечь массы низкоквалифицированых, что даст более глубокое разделение труда и понижение ЗП в индустрии.
Здравствуйте, vsb, Вы писали:
vsb>Я тут уже весь форум своими темами завалил, простите.
vsb>Захотелось высказаться по теме сабжа. Я в самом ИИ ничего не понимаю. Но люблю им восхищаться и даже немножко профинансировал микрософт покупкой подписки на копилот, коим пользуюсь. vsb>...
Хорошо заметно внедрение искусственного интеллекта в электронные устройства, кнопки управления если и присутствуют, то становятся лишь декоративными, а реальное управление осуществляет искусственный интеллект. Ну а если пользователь хочет сделать совсем не то, что делает встроенный в устройство искусственный интеллект, — это проблемы самого пользователя.
Здравствуйте, Baiker, Вы писали:
B>Я не голословен — мы УЖЕ почти потеряли WPF: несмотря на всю декларативность, так и остался windows-only.
MS похоронила много технологий, а кроссплатформенный GUI у них уже лет дцать взлететь не может. К среднему качеству программистов по больнице это никакого оношения не имеет.
Кому нужен серьезный кроссплатформенный GUI, те используют Qt уже лет дцать.
Здравствуйте, Nuzhny, Вы писали:
N>Насколько я понимаю, мы пока получили базу ответов со SO уже не где-то там в гугле, а у себя в IDE. Если раньше приходилось их искать,читать темы и анализировать, то сейчас просто анализировать. Делает ли SO программистов умнее или тупее?
Скорее делает быстрее, т.е. помогает решать проблемы быстрее. А там уж как получится.
